Re: Velocity vs. FreeMarker
Rather than fill out a detailed checklist, which issues are of the most concern? The latest version of Velocity (currently unreleased but in the nightly source code drop) supports decimal numbers in templates. That used to be a significant issue that's now gone away. When you're comparing, be sure to look at Velocity's sub-project, Velocity-Tools, which adds integration with Struts, JSP, servlets, etc. It also provides a number of tools to do useful tasks like formatting, etc. Best, WILL - Original Message - From: Meikel Bisping [EMAIL PROTECTED] To: velocity-user@jakarta.apache.org Sent: Thursday, February 24, 2005 10:09 AM Subject: Velocity vs. FreeMarker Hello, the FreeMarker people claim that FreeMarker is more advanced in some respects. Could you check if that's (still) true ? You can edit the page: http://confluence.atlassian.com/display/TEST/Velocity+vs.+FreeMarker Cheers, Meikel Bisping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity vs. FreeMarker
The Velocity language is simple and powerful, as well as very fast. In a well-designed application, the template designer can be placed in a sandbox of data and tools and left to play happily without supervison. The fact is, anything can be done in Velocity, in a nicely organized way, given cooperation between the programmers and template designers. Beware of the allure of having more programming type options within the templating language. In fact, a lot of folks judge a view application (such as Velocity and FreeMarker) as most effective when the designer has few options to manipulate data; they only decide how to present it. The more complicated the programming of the template, the more programming expertise will be required of the template designers. The Velocity developers have made very conscious decisions to keep the core language as simple as possible. This, in turn, makes the templates easy to write and maintain. There is a wide spectrum of just how much control should be given to the programmers vs. designers when it comes to templates. Within this spectrum, FreeMarker gives more control to the template designer, with more tools included in the core language. Velocity gives more control to the programmer, providing additional tools as appropriate. Many tool programs have already been written and are readily available in the Velocity Tools project. I might also add that the Velocity community is very helpful and supportive. Super, in fact! Barbara Baughman X2157 On Thu, 24 Feb 2005, Meikel Bisping wrote: Hello, the FreeMarker people claim that FreeMarker is more advanced in some respects. Could you check if that's (still) true ? You can edit the page: http://confluence.atlassian.com/display/TEST/Velocity+vs.+FreeMarker Cheers, Meikel Bisping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity vs. FreeMarker
Nice summary. Choosing a tool is more than hitting a checklist of features. Good design and ease of use are also important. Having said that, if there's specific questions or concerns you have, this is a good place to ask about them. WILL - Original Message - From: Barbara Baughman [EMAIL PROTECTED] To: Velocity Users List velocity-user@jakarta.apache.org Sent: Thursday, February 24, 2005 2:11 PM Subject: Re: Velocity vs. FreeMarker The Velocity language is simple and powerful, as well as very fast. In a well-designed application, the template designer can be placed in a sandbox of data and tools and left to play happily without supervison. The fact is, anything can be done in Velocity, in a nicely organized way, given cooperation between the programmers and template designers. Beware of the allure of having more programming type options within the templating language. In fact, a lot of folks judge a view application (such as Velocity and FreeMarker) as most effective when the designer has few options to manipulate data; they only decide how to present it. The more complicated the programming of the template, the more programming expertise will be required of the template designers. The Velocity developers have made very conscious decisions to keep the core language as simple as possible. This, in turn, makes the templates easy to write and maintain. There is a wide spectrum of just how much control should be given to the programmers vs. designers when it comes to templates. Within this spectrum, FreeMarker gives more control to the template designer, with more tools included in the core language. Velocity gives more control to the programmer, providing additional tools as appropriate. Many tool programs have already been written and are readily available in the Velocity Tools project. I might also add that the Velocity community is very helpful and supportive. Super, in fact! Barbara Baughman X2157 On Thu, 24 Feb 2005, Meikel Bisping wrote: Hello, the FreeMarker people claim that FreeMarker is more advanced in some respects. Could you check if that's (still) true ? You can edit the page: http://confluence.atlassian.com/display/TEST/Velocity+vs.+FreeMarker Cheers, Meikel Bisping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity vs. FreeMarker
Friday, February 25, 2005, 2:04:34 AM, Will Glass-Husain wrote: Nice summary. Choosing a tool is more than hitting a checklist of features. Good design and ease of use are also important. From my standpoint the point is that the FM Vs Vel. page should be updated, since it was made for Vel 1.2, and thus probably outdated. Or it has to be removed... but I think that doesn't server the users well. Having said that, if there's specific questions or concerns you have, this is a good place to ask about them. WILL -- Best regards, Daniel Dekany Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. Probald ki most! http://www.freestart.hu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity vs FreeMarker
Sure. This way it's even easier to refer to it than if it were only in the mailing list archive. Attila. - Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 2002. január 16. 0:18 Subject: Re: Velocity vs FreeMarker Attila - thanks for such a thoughtful article. Can we put in on the site? I assume we have your implicit permission, but I thought I would ask. snip/ -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Now what do we do? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] smime.p7s Description: application/pkcs7-signature
Re: Velocity vs FreeMarker
True, and this is a really useful function; at least I know it saved me considerable
effort several times.
It'd make sense having that in Velocity as well, namely if
#set $foo = "bar"
then a hypothetical expression
$obj[$foo] would evaluate to $obj.bar
Maybe the community should discuss the addition of this feature to Velocity.
Attila.
- Original Message -
From: "Lev Epshteyn" [EMAIL PROTECTED]
To: "'Velocity Users List'" [EMAIL PROTECTED]
Sent: 2002. janur 15. 16:34
Subject: RE: Velocity vs FreeMarker
snip/
One feature of Freemarker that you neglected to mention that I find missing
in Velocity is the dynamic resolution of entities. I.E:
assign foo = "Price"
The cost is ${object["get" + foo]}
With Velocity this kind of thing only works if I want to call get("Price")
but not for getPrice() which I think is a little limiting.
-Original Message-
From: Attila Szegedi [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 15, 2002 6:13 AM
To: Velocity Users List
Subject: Re: Velocity vs FreeMarker
Frankly, this question has popped up quite several times on this list, so
I've decided to write a comparison that is to my best knowledge detailed and
fair; If the issue comes up in future (it will...) we'll be able to settle
it by sending people off to the archives...:
Here it goes:
1. Licensing: Velocity is Apache-licensed, Freemarker is LGPL. LGPL is
somewhat more restrictive, altough it also allows commercial use. It
(roughly) means that if integrated into a closed source product, you still
have to ship Freemarker sources with it. OTOH, for Velocity you just have to
retain its copyright notice and give credit in your product's documentation
and/or about box. Be sure to read and understand both licenses, though.
2. Servlet support: both have equally good servlet support, with alike
features.
3. XML support: Velocity has XMLEasyBean and Freemarker has NodeListModel.
Both allow for accessing XML content with syntax like
"document.element.subelement.subelement" etc. Freemarker also supports XPath
directly on elements (with nodelist("xpathExpression") syntax), as well as
several "magic keys", like nodelist._descendants, nodelist._ancestors,
nodelist._unique (these are there mostly to alleviate the need for an XPath
package), nodelist._content, nodelist._text, etc. I don't know for
XMLEasyBean, but a Freemarker XML NodeList renders itself into the template
output as the XML fragment of contained JDOM nodes. Freemarker's XML
integration also supports XML namespaces quite elegantly (you can use
constructs such as $document._registerNamespace("rdf", "http://...") and
later on $document["rdf:RDF"]["rdf:Description"]). Note that the template
can use different namespace prefixes than the actual XML document uses -
only the URI matters.
Velocity has another level of XML support as well: there's
org.apache.velocity.anakia.AnakiaJDOMFactory class; if you generate your
JDOM document using that factory, then stick its root element (an instanceof
AnakiaElement) into the context, you'll gain the ability to evaluate XPath
expressions on the element directly ($element.selectNodes("xpath")). Also,
rendering an element, or a list of JDOM nodes returned through either
selectNodes, getChildren, etc. will also produce the XML fragment
representing the element/nodes. However, with AnakiaElement, you don't have
the ability to write "element.subelement" (like with XMLEasyBean), instead
you need "element.getChildren("subelement")". Since Velocity directly
exposes JDOM elements, you can use namespaces with AnakiaElement, too
altough (as I percieve it) you'll have to use unintuitive hacks to obtain
arbitrary namespace (something along
$element.getNamespace(),getNamespace(uri, prefix)).
So, as things stand now you have two levels of XML support in Velocity: one
gives you intuitive navigation syntax, the other gives you XML fragment
rendering, XPath, and Namespace support, but none gives you all features at
once as the Freemarker solution does.
4. Ant integration: both have Ant task for transforming XML documents
through templates. Velocity's is Anakia, Freemarker's is based on the
NodeListModel. They are pretty much similar (since Freemarker's is
admittedly writen by taking and modifying Anakia code). Velocity has another
Ant task, Texen but I'm not familiar with its purpose enough to say anything
reasonable.
5. Macros: Velocity has Velocimacros, and Freemarker has functions. Both
can take parameters, call other macros, and act recursively.
6. Number support: Velocity supports operations on integers. Freemarker only
deals with strings.
7. Basic philosophy: now, this is very different. Freeemarker is built
around interfaces: dictionary, list, method, and sca
