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

Tim Diggins wrote:
> just intervening from the sidelines really, wondering if wm syntax is  
> needed within freemarker, 

Well, it's certainly not *needed* in any real sense. The truth is that I 
started doing what Demetrios requested mostly just to explore the 
question of how difficult supporting an alternative parser was generally.

It turns out that I could plug the Velocity parser into the FreeMarker 
rendering engine and it was a mini-project that took a few hours. As I 
said, it's a funny thing, because the resulting hybrid tool is actually 
significantly more capable than Velocity itself, since it reads all the 
same Vel templates using the same parser, but since it uses the 
freemarker engine for rendering, it gives you proper error reporting 
with line numbers and so on. And typical programming stuff, like nesting 
macro calls recursively now works because, unlike the Velocity rendering 
engine, it doesn't pass all macro parameters in as values, not as 
strings to later be reparsed (!) Not to mention automatic i18n of 
numbers and dates... just off the top of my head, surely there are other 
things...

So the resulting hybrid from the half-day hack is a greatly improved 
version of Velocity, but a terribly crippled version of FreeMarker. No 
local variables in macros, no namespaces, no forward referencing of 
macros, no declaring macros with default parameters, or invoking them 
with named parameter lists... And so on. But OTOH, AFAICS, it supports 
every construct in Velocity...

(Oh, just remembered... no macros with blocks, i.e. no <#nested>.... 
that's a big one...)

It is hard to see why somebody would use such a crippled tool for the 
dubious advantage of being able to write #set ($foo = "bar") instead of 
<#set foo = "bar"> and so on. The person who wants a more capable tool, 
how hard is it really to switch your templates over, especially when we 
have a freebie conversion tool that handles most of the drudgery?


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

Well, actually, we have a tool that converts the syntax, so this could 
be automated. The problem is that it uses the Velocity parser itself to 
convert the syntax. So whatever problems there are in the 
above-described experiment also occur this way. So it's tweedle-dum and 
tweedle-dee.

Unless we actually were to write our own .vm parser and probably extend 
that syntax to fully support FM's capabilities, it would never be more 
than a proof of concept experiment.

OTOH, if we were to really design an alternative syntax that supported 
the full FM feature set, even if it was kind of inspired by the Vel 
syntax, it is unlikely that we'd end up with something that was really 
fully backward compatible with Velocity, i.e. existing Vel templates 
still would not work without modification...

Of course, given that, once one really thinks about it, I think you come 
to the conclusion that it's better to just go completely blue skies and 
forget Vel and forget the current FM and design a potentially more 
appealing syntax from scratch. At least, assuming one is going to really 
invest some serious effort in an alternative syntax, it's not strictly 
"needed"...

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

Oh, defining your macros in ftl and including them with a wm syntax 
would work, I guess. Still, we'd need a new parser for the Vel side, 
since you can't express a macro invocation with an associated block, 
say, in VTL. There is currently no syntax for it. Well, OTOH, you would 
be able to invoke the macros leaving out the optional parameters, say, 
from the VTL side. Some extra advantages. ANd, of course, all the macros 
defined in FTL would be able to fully exploit FM's feature set.

But OTOH, hold on... what's the point? You end up with a system where 
part of your front-end is ftl syntax and part is vtl syntax? Again, it 
would be crazy. You'd just realize that you are better off switching to 
all templates using ftl and be done with it. FTL alone is obviously 
simpler than FTL+VTL.

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

An idea came out of this that I think I will implement in the next, I 
dunno.. few days or so... A java applet that lets you write VTL in a 
text box and then displays the equivalent FTL. That's easy... if I could 
remember how you write and deploy an java applet....

I was originally thinking of making it a servlet and was thinking about 
where to put it and so on, and then I remembered that applets still 
exist. (Don't they??? :-))

So on the same page where people can download the converter, we just put 
an applet there that allows people to input (or paste) any VTL snippet 
and it just spits back the equivalent FTL...

Cheers,

JR

P.S. If you want to volunteer to write the applet, it's real simple, 
I'll point you to the code you need...


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


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