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

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

Since you're asking for this, I think there are a couple of things you 
should be willing to do.

(1) Do some testing. (Ideally even write some unit testcases.)

(2) When it's fairly polished, announce it on the Velocity list. (I'm 
tired of talking to those people...)

To test the first pass implementation, you need to check out the code 
from SVN.

That is here:

svn co 
https://freemarker.svn.sourceforge.net/svnroot/freemarker/tools/vel2ftl

You will need a latest bleeding edge freemarker.jar build on your classpath.

You can get that from our bamboo server: http://freemarker.org:8085/

Click on the latest build from the trunk (169 right now) and then the 
artifacts tab and get the library. You'll need that on the classpath to 
build the source that you checked out.

There is a main that you can run,

java freemarker.tools.vel2ftl.VelBridge <filename>

that take a velocity template file and runs it with an empty data model.
Well, what it does, is it converts it internally to a FreeMarker syntax 
tree and runs it using the freemarker machinery. The class that does the 
work, if you're interested, is VelNodeToFTLNode.java.

If you want to test it in your own app, you need something like:

Configuration config = new Configuration();
....
config.setDirectoryForTemplateLoading(...)

And then (and this must be AFTER you set where the templates are to be 
loaded from) you need:

conf.setTemplateCache(new VelBridgeTemplateCache(conf.getTemplateCache()));

The VelBridgeTemplateCache is a trivial subclass of the regular 
TemplateCache that will load templates using the velocity parsing 
machinery IF the template's name ends in .vm OR .vtl. Otherwise, it 
behaves normally, just loading in freemarker templates. So, any files 
you test have to end in .vm or .vtl. This means that it parses it using 
Velocity, and then walks the Velocity tree and produces a FreeMarker 
tree. Then merging is done with the FreeMarker engine.

I've done a little testing. It seems to work for basic stuff at least. I 
tested an if-else, a macro or two.... The big caveat right now is that 
the location info is missing. And that, of course, is what allows 
quality error messages, one of FM's biggest advantages. But that is 
remediable. Just some more work.

Note that if you have an instance of VelBridgeTemplate (a trivial 
subclass of the regular freemarker.template.Template) it has a merge() 
method with the same parameters as the Velocity Template object. OTOH, 
the exceptions it throws are different... oh well... but your compiler 
will catch that and you can fix it up.

Anyway, you asked for this, so I think you should test it out now.

JR


Demetrios Kyriakis wrote:
> 
> Daniel Dekany wrote:
>>> This would not be a problem cause it's not required as the actual
>>> implementation is using Velocity, and
>>> the main reason for switch would be the fact that this engine is alive,
>>> not
>>> the extra features.
>> Despite of Velocity is not evolving (as you said), what benefit you
>> hope from switching to FM if you have to keep the old templates as-is,
>> and you don't need any extra features either? 
>>
> I mean no other features that affect the template syntax (the one the users
> are used to), not the engine and the rest.
> What advantages? I'm not a FreeMarker expert so I can't comment, but in our
> migration draft I see things like:
> - direct advantages:
>    - a better designed API
>    - better error reporting
>    - less errors in the engine itself
> 
> - potential advantages (due to the evolution - the project is alive):
>    - possible increase in speed
>    - possible even better error reporting
>    - possible FM level debugger.
>    - possible support for precompiled templates.
> 
> - indirect advantages:
>    - missing of the ever increasing Apache.org bureaucracy.
>    - issues usually don't stay unsolved for years in the tracker.
>    - patches are usually accepted (don't remain unused in the tracker)
> 
> 
> Daniel Dekany wrote:
>> I mean, if you just will have Velocity templates after the switching, then
>> what is changed for
>> you then?
>>
> For me alone the simple fact that V... is practically abandoned would be a
> reason enough for a switch :).
> 
> Thank you,
> 
> Demetrios.
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/