Velocity 1.4 Released

JohnA writes "After what seemed to be a 30 year beta period, the Apache Jakarta team has made available the final release version of Velocity 1.4. If you're not familiar with Velocity, it's one of the most powerful and popular templating engines around. And, as an added bonus, a DreamWeaver plugin was also released."

Comments

Re:Why?

[HawkingMattress]

Because JSP sucks.
It is hard to debug, and encourages bad practices like putting some java code directly into the JSP, which then becomes a logic and presentation layer instead of just presentation. JSP is the thing you'd want to create a quick and dirty app, but it's sadly an enterprise standard. Now you can try to force everyone to use it as a sole presentation layer, but in many cases, it's very tempting to juste add a little scriplet, because it gets the job done. Then one day you realize your CMS or whatever has become very hard to maintain because there is logic everywhere and you have to recode the whole thing to keep the maintenance costs low.
The problem is, that's exactly the type of problem that J2EE is supposed to address, but JSP makes it hard because it's too easy to shoot yourself in the foot.

Re:Why?

[aminorex]

JSP is horrible because it is designed to produce badly designed code. Bad design, by design. You see, in JSP the crucial, central aspects of presentation and business logic tend to become increasingly intertwined, because there is Java code
implementing business logic intertwingled with your presentation HTML, and vice versa contrariwise.
This is not a happy peanut butter cup land.

PHP and ASP have the same problem. PHP is actually even worse, because, although there are template engines for PHP, they lead to spaghetti objects, where a single aspect is smeared over umpty-booty-teen different class files. Good luck maintaining that when the project grows past 10kloc! (I won't even BEGIN to address the death-march misery that is ASP.NET.)

Struts, Velocity, and JSF together make a beautiful system, in which the classic MVC patterns apply, aspects are colocated, and presentation is sharply segrated from business logic. Now that, my friend, is a real step ahead of the competition. Websphere is the only commercial environment that really supports this stuff right now, although I expect WebLogic to catch up soon. The Dreamweaver support is velly intelesting to me as well.

It's a good time to be alive.

Re:Why?

[Anonymous Coward]

It's handy for things that aren't going to be webpages too. I use it for templated SQL queries, XML documents and so on.

Re:About time...

[iroberts]

I would recommend Jamon, which is for Java what HTML::Mason is for Perl. Rather than "throwing variables over a wall" from java code to templates via a context object (basically a hash map), templates declare themselves to expect certain arguments, which are passed to them from Java code. For example, HelloWorld.jamon might contain:

<%args>
String name;
</%args>
Hello <% name %>!

This would be called from java as

new HelloWorld().render(System.out, "Taco");

Any java types can be passed to a template (primatives and objects). Templates can both inherit from and call other templates. Everything is staticly type-checked at compile time. Automatic template recompilation is supported during development, and in production, no reflection is used.

I'd rather use Tapestry

[chochos]

I think Tapestry (now adopted by jakarta too) is a better replacement for JSP. It's a lot easier to use than Struts, requires less configuration, has a nice plugin for Eclipse (spindle), and has a very elegant design, that allows for a lot of extensibility and reuse while keeping presentation separate from logic. The only drawback, really, is that's it not JSP and some people have a problem with that. Struts as I see it is a patch on top of JSP. JSF, JDO, and some other initiatives by Sun are just attempts to catch up with more advanced, robust and mature open source projects like Tapestry, Hibernate and the like.

Re:I'd rather use Tapestry

[Anonymous Coward]

JSP with Struts looks a lot like HTML. That's a big advantage. Give it to a web guy, and tell him to use instead of , etc., and he can do the view work for you while you focus on model and controller.

Re:I'd rather use Tapestry

[chochos]

Well, Tapestry looks EXACTLY like HTML. You don't really use any special tags (forget about <%tags%> and and such), you just use a special attribute in the tags you want to process as Tapestry objects, for example you can do this for a page link.
You can easily write your own components and have them contain other components, etc. It's really versatile and powerful. You can also get the html from a web guy, add the jwcid attributes, give it back to the web guy, etc.

Re:I've got some karma to burn too

[Anonymous Coward]

Apache is not just the web server, but all projects run by the Apache Software Foundation. There are quite a few, especially in relation to J2EE, that are of great interest to enterprise developers. Most of the high school kids on /. don't ever see this backend stuff, so they tend to keep away from this section.

Re:Why?

[yadayadayada]

PHP is actually even worse, because, although there are template engines for PHP, they lead to spaghetti objects

Smarty, the most popular PHP template engine, is actually very similar to Velocity. Velocity has a more pleasant syntax, while Smarty has more features (esp. caching). One is certainly a knock-off of the other. I don't know which was first, though.

Re:Why?

[wglass]

A big advantage of Velocity is that it combines a flexible templating language with ease of integration into existing applications and frameworks. Because of this, a lot of java-based web frameworks include Velocity support. Struts, WebWork, Turbine, Maverick, Spring, to name a few. Using Velocity it's also possible to roll your own web markup language with Velocity as a base, as the folks on the Roller team have done.

In addition, Velocity is more than just a web scripting language. (as opposed to JSP which is almost exclusively that). Besides using it to create web pages in a webapp, I have made Velocity templates to assist my applications in sending email and have made templates to auto-generate code to help with my object/relational mapping. There's also a translation to C# called NVelocity.

Obligatory WebMacro plug

[MCRocker]

WebMacro has moved into the beta phase of release 2.0!

WebMacro is the original templating engine that velocity is based on. Unfortunately, due to licensing issues, they were never able to merge and have now diverged enough that they are now quite different despite the base similarities.

Version 2.0b1 of WebMacro has new and exciting features as well as efficiency gains. One of the most interesting new features is actually a result of the improvements in Java technology itself. The older versions had a lot of factories and contexts in order to get around the inefficiencies of object creation and clean-up, but now, much of this has been removed or hidden because of improvments in Java garbage collection has made them supurflous.

Re:Why?

[mrtom852]

One of it's advantages is that it can be used outside of a JSP server - so normal applications can use it as a light weight template engine.

Personally I don't like Velocity, but I think it's because I'm in a very XML based environment. As a web presentation layer I use JSTL/taglib and avoid the old school JSP code 'tags'. This way it's closer to XML but I still wish the spec made it fully XML compliant.

When JSPs don't make sense I will always use XSL because the templates can be run on any platform.