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

Daniel Dekany wrote:
> Monday, March 24, 2008, 11:46:39 PM, Jonathan Revusky wrote:
> 
>> Okay, Demetrios, I have a first pass written now. I mostly did this
>> as a technical challenge. I was curious to see how hard it is.
>> (Answer: not very hard, I don't think.)
> [snip]
> 
> What did you done with the semantical differences regarding missing
> variables? (I suppose you don't print $noSuchThing (literarily; that's
> how it works in VM) for $noSuchThing.) With the more loose boolean
> logic (e.g. #if $noSuchThing)? And with the interpolation semantic? As
> you know, VM uses toString(), while we are using localized format by
> default... that can cause 1234 to become 1,234 and like, that can be a
> problem. Oh, and the horror of horrors... with assignments? You know,
> when #set(x = $noSuchThing) just does nothing. Ugh... it would feel
> perverted to emulate this. :)
> 

BTW, there was stuff that traditionally doesn't work in Velocity, but I 
thought would work if we rendered using the FreeMarker machinery.... 
BUT... it still doesn't work.

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... 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.

Too much work, I suppose... I mean... one just very quickly sees that 
there is no way to build any product of decent quality on top of 
anything that community did. Now, this VelBridge I wrote actually does 
work. It reads in all Velocity templates pretty much and uses the far 
better FreeMarker engine to render, so, as you see, you get decent error 
messages if you're missing a parameter in a macro call and you get 
localization of dates and numbers and all that stuff.

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....

Who would be interested in this? Why wouldn't they just use FreeMarker? 
I have heard nothing from the guy who supposedly wanted this. An 
interesting experiment nonetheless.

If we wanted to actually offer something like this, we would need to 
write our own parser for Velocity syntax, because it's the only way we 
could have any quality. But that leads to the following question:

Is there an extended velocity syntax that could offer FreeMarker's 
capabilities but would be backward compatible with Velocity templates 
(most of them at least)?

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... 
but I don't think that a crippled FreeMarker that uses Velocity syntax 
is really very appealing.

JR


-------------------------------------------------------------------------
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