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

About time...

[JPelzer]

Now we can finally start another Jakarta templating project that does almost exactly the same thing, but not quite, but our description of the project will claim our version is superior, with a name that has nothing to do with what the project does. How about "Project Platypus" ?

Project Platypus Overview:
"Similar to Velocity, but with some important differences: Mainly, we've added several reptilian characteristics which include using the same opening for reproduction and eliminating waste products, the ability to lay eggs, cervical ribs, and local ascorbic acid synthesis in the kidney. Also, Project Platypus can swim."

Re:About time...

[mhesseltine]

Not trolling here: if Velocity is, as you say,

"another Jakarta templating project that does almost exactly the same thing, but not quite, but our description of the project will claim our version is superior, with a name that has nothing to do with what the project does."

Does that imply that there is a "standard" or in your opinion better templating project in the Jakarta project?

I've been interested in learning Java/JSP/etc. and would love to hear your recommendation on a good engine to study.

Re:About time...

[benwb]

Tapestry

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.

Re:About time...

[the quick brown fox]

You should definitely at least learn JSP first. For all its faults, it's still the standard templating mechanism for J2EE, and you can't really call yourself a Java web developer if you don't know it.

Once you learn it and loathe it, then you can move on to others.

I personally think GroovyPages looks like it could be a much better solution than anything else I've seen in the Java world. But then I like having the option to write powerful code in the presentation layer, while the whole point of Velocity is to take that power away from you.

Re:About time...

[Anonymous Coward]

That's actually really cool... I've always hated the hash map approach to parameter passing, especially when all of the other code in your monster J2EE app is totally statically type-checked. Can't count the number of times I've seen bugs from misspellings in calls to session.getAttribute() and whatnot.

Why?

[forsetti]

Why do we need an alternative to JSP, that also works in a Java environment? I understand the use of JSP as an alternative to PHP or ASP (3 different platforms), but I don't understand why I need two solutions to (seemingly) the same problem on the same platform. Could someone enlighten me?

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:Why?

[Anonymous Coward]

Why not use PreparedStatement? Not only does it template your SQL, but it increases performance to boot.

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.

Re:Why?

[julesh]

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.

I'll admit my exposure to JSP is limited, but this isn't a problem I had with it when using it.

You just need to think about your application design before sitting down and coding it.

Separation of presentation and logic is simple to achieve using standard practises and commonly available extensions (such as producing an XML document and formatting it through an XSLT or similar stylesheet) without throwing out the entirity of JSP, which is a useful framework for bringing together information from various sources quickly and easily.

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'll admit I've never written a 10kloc PHP project, but my last one reached 6.5k and doesn't suffer from the problems described. I used the following architecture:

- a standardised framework for modules and methods within the modules allowed core site code to call methods without having to know about the module (e.g. by using user provided input). This was guided by a security framework to ensure that only appropriate methods were called

- methods produced data in a standardised format (an associative array of key -> value or key->{array of arrays in the same format}) which could be easily mapped to either XML or encoded through a template engine

- all presentation information was written in a simple templating environmnent.

Not too complex, and achieved what was needed easily. It would also be relatively easy to expand the system further.

I fail to see the problem.

Re:Why?

[mmcshane]

The most important difference for me is that Velocity is not tied to server side servlet processing. JSP templates cannot be used outside of a servlet container (they are in fact compiled into servlets at runtime) however Velocity templates can be used in any context. I personally have used Velocity to do source code generation and offline report generation.

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.

Re:Why?

[the quick brown fox]

I've spent most of the past 5 years doing Java-based web development. I fully agree that PHP is a nightmare compared to (insert favorite combination of Java frameworks and toolkits here).

However, I think ASP.NET is better. It's a huge shift from ASP; you could say ASP to ASP.NET is like PHP to JSF. (In fact, I believe JSF was created entirely as a response to ASP.NET, though they didn't do nearly as nice a job.) ASP was (iirc) a fully interpreted HTML embedded language. ASP.NET pages are precompiled (a la JSP) and represent much more than embedded code; it is a rich framework for transparently mapping client state and events onto the server side, and provides extremely clean mechanisms to react to those events in ways that modify the UI.

I do a lot of rich client GUI work now, the kind of work where those MVC patterns originated, and I can tell you for sure that ASP.NET makes it possible to track much more closely to that model than you can with the current state of the art in Java land.

Big caveat: I do have to admit I haven't actually used ASP.NET for a real app, only read the book and played around with it. (For all the elegance of the framework and programming model, I can't bear the thought of actually deploying a webapp on a Windows server.) But everyone I've talked to who has done both Java and ASP.NET development has thought the latter was better.

Re:Why?

[Captain_Chaos]

...intertwingled...

...vice versa contrariwise.

...happy peanut butter cup land.

...spaghetti objects...

...umpty-booty-teen...

...10kloc!

...death-march misery...

There has got to be some creative language usage award I can nominate you for, and if not, I move that we create one...

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.

It's Not by Design

[arthurs_sidekick]

JSP is not *designed* to produce crappy code, even if a lot of people produce crappy code with it. Hell, the same goes for PHP, although the latter's genesis as an HTML-embedded language does, I believe, expose it to that sort of charge.

There are reasons for servlet forwarding and tag libraries; they let you do the heavy lifting in servlets and tag handlers, and just handle display in JSPs.

I say this as the author of several JSPs (some deployed in production on reasonably high-profile sites) with buttloads of spaghetti-code, static Java blocks, and their own methods(!). I did it all out of ignorance of the true power of the tools the Serlvet spec designers put in my hands. It's an education issue more than a spec design issue.

Of course, there is that undercurrent among Java developers that suggests if the language permits a certain practice, it encourages it. That's what you get for designing a "B&D" language =)

What I like most about Velocity

[osewa77]

Is that, unlike technologies like JSP, Velocity works simply as a component, a module, which you can adapt for various purposes in your application. I don't believe in frameworks, I believe in modules which have their source code available.
- A Small-time Nigerian Weblog Publisher

Re:What I like most about Velocity

[doktorjayd]

.. but... .. isnt a framework really jsut a collection of components?

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.

I just want to know...

[Anonymous Coward]

Can I write FORTRAN in it?
Is there an Emacs mode?