Re: Any plans for a 100% wm syntax compatibility?

just intervening from the sidelines really, wondering if wm syntax is  
needed within freemarker, or whether a loosely coupled solution might  
be better...

Assuming it would be acceptible I think to have a solution that  
supported a (large) subset of *.wm syntax: In the ideal it would  
report any failures (e.g. macro defined before use, macro redefined),  
but in worst case might break or just work differently for very  
complicated/anomalous *.wm scripts / advance features.

If there a way of converting a wm file (see above) to ftl file. You  
could then use this as a one-off or as a  template pre-processing step  
to convert syntax from wm -> ftl. This doesn't have to be performant,  
as template caching could be on in production, and even (in worst  
case) be required/suggested as a build/compile step for going to  
production.

In the ideal this step might be just a part of use (ie. macros defined  
in ftl, but included using wm syntax).

Just my 10c worth - not meaning to tell granny how to suck eggs...

Tim


On 1 Apr 2008, at 10:47, Demetrios Kyriakis wrote:
>
>
> Jonathan Revusky-3 wrote:
>>
>> For example, forward referencing and reassignment of macros. Consider
>> forward referencing.... this example works:
>>
>> #macro (foo) Hello, World #end
>>
>> #foreach ($i in [1..5])
>>    #foo
>>
>> #end
>>
>> produces:
>>
>>     Hello, World
>>     Hello, World
>>     Hello, World
>>     Hello, World
>>     Hello, World
>>
>> But suppose we put the macro definition at the end of the file  
>> instead
>> of the start. This is the case that Velocity cannot handle and will  
>> just
>> output a literal #foo. In this Velocity-bridged FM, it produces:
>>
>>     Hello, World ()
>>     Hello, World ()
>>     Hello, World ()
>>     Hello, World ()
>>     Hello, World ()
>>
>> IOW, in the first case, the Velocity parser parsed () as part of the
>> macro invocation but in the second case, when we forward reference,  
>> the
>> () is treated as plain text.
>>
>> Of course, this means that it doesn't work with macros that take
>> arguments. Now, this works correctly:
>>
>> #macro (foo $bar) Hello, $bar #end
>>
>> #foreach ($i in [1..5])
>>    #foo("World")
>>
>> #end
>>
>> but when you put the macro definition at the end, you get:
>>
>> Parameter bar unspecified.
>> ----------
>> ==> macro foo [on line 6, column 1 in duck.vm]
>>  in user-directive foo [on line 3, column 4 in duck.vm]
>> ----------
>>
>> Java backtrace for programmers:
>> ----------
>> freemarker.template.TemplateException: Parameter bar unspecified.
>>         at
>> freemarker 
>> .core.ast.ParameterList.getParameterMap(ParameterList.java:186)
>>
>> etcetera.
>>
>> IOW, it was parsed as #foo followed by the plain text ("World")
>>
>> Same sort of problems occur with aliasing a macro.
>>
>> #macro (foo $bar) Hello, $bar #end
>> #set ($alias = $foo)
>>
>> #foreach ($i in [1..5])
>>    #alias("World")
>>
>> #end
>>
>>
>> Parameter bar unspecified.
>>
>> etcetera.
>>
>> Well... this is all such junk...
>>
> Yes, it is junk, but in our case, the users (non-programmers) don't  
> write
> macros, and only use a few
> predefined ones in thier "more text"-oriented templates.
>
>
> Jonathan Revusky-3 wrote:
>>
>> I googled a bit for some discussion of
>> this and quickly found:
>>
>> http://wiki.apache.org/jakarta-velocity/MacroIssues
>>
>> The whole thing is just completely FUBAR'ed. What's interesting about
>> this is that these guys maintain pages like the above one, but then
>> don't ever draw the obvious conclusion, which is that if they really
>> want to have a product of some kind of decent quality, they need to
>> rewrite the parser.
>>
> I think, in order to draw conclusions, one needs to understand the  
> thing,
> but since
> the original authors are all gone, ... :).
>
>
> Jonathan Revusky-3 wrote:
>>
>> But.... even if this bridged thing is better than Velocity, it is so
>> inferior to using FreeMarker itself, it's not funny. No namespaces,  
>> no
>> local variables, no macros with blocks, no visit/recurse machinery  
>> for
>> processing XML, no built-ins....
>>
>> From a programmer's point of view you are right, but for the non- 
>> programmer
> user all
> those concepts are not important. They only care about the simple  
> syntax
> (V.. happens
> to have).
>
>
> Jonathan Revusky-3 wrote:
>>
>> Who would be interested in this? Why wouldn't they just use  
>> FreeMarker?
>>
> Because of the V.., (better said  *.wm)  syntax.
> It is of course very primitive, but for the non-programmers already  
> the
> upper limit they're able (or ready) to learn.
> "Less is not more", but just what they need (and feel confortable  
> with).
>
>
> Jonathan Revusky-3 wrote:
>>
>> I have heard nothing from the guy who supposedly wanted this. An
>> interesting experiment nonetheless.
>>
> Sorry, but I'm not ready with the tests I promissed.
> I'm working on a compatibility test suite (and I had to start with the
> documentation first to get the approval :) ).
> It is not bound to this velocity bridge, but it's generic to use  
> with any
> framework that could produce
> compatible results with Velocity, so that when it's there, with  
> minimal
> effort to be able to test that compatibility.
>
>
>
> Jonathan Revusky-3 wrote:
>>
>> I think it could be interesting to work up an alternative parser for
>> that syntax and offer it. Also, by breaking out the syntax like  
>> that, it
>> would clean out a lot of FreeMarker's basic design. So it's an  
>> idea...
>>
> Of course, this sounds much better since than the V.. dependency would
> be 100% gone :).
>
>
> Jonathan Revusky-3 wrote:
>>
>> but I don't think that a crippled FreeMarker that uses Velocity  
>> syntax
>> is really very appealing.
>>
> I suppose this is because you think all the time like a programmer :).
> If you would have to deal with non-programmers (and thier number is  
> much
> higher than ours) you would quickly see where are their limits :).
>
> Demetrios.
> -- 
> View this message in context: http://www.nabble.com/Any-plans-for-a-100--wm-syntax-compatibility--tp16197027p16417098.html
> Sent from the freemarker-user mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user

Tim Diggins
http://red56.co.uk/people/tim






-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace