Velocity 1.5

by Dejan Bosanac

As you all have probably heard, Velocity 1.5 was released last week. It is the first release of this project in last three years. This is certainly a long release cycle and it is not unusual that some people considered it a "dead project".

I have some projects that use Velocity as a template engine of choice and over the time I've collected a "wish list" of features that I missed. Due to lack of new releases, I've considered switching to other template engines, such as FreeMarker and WebMacro, but actually never found time to do that.

As I go through the release note, I see that some of the wish-list features have been added to this release. Some of them would be nice to be seen in the future (road map looks promising). Here are some details:


Jonathan Revusky
2007-03-21 19:13:27
Velocity 1.5 would, I think, not even be quite competitive with versions of FreeMarker released 5 years ago, FreeMarker 2.1.x. Since then, there were two major release cycles, 2.2.x and 2.3.x. which added a lot of very useful things, and basically left Velocity completely in the dust.

In general, all the things you want -- the break statement, for example --- are already available in FreeMarker, and have been for years.

On the other hand, your idea of automatic string to number casting is rather dubious, you know. How do you cast the String "1,234" into a number? An American thinks this string represents an integer bigger than a thousand and people in Europe think that it represents a number a bit bigger than 1.

The problem is that you need more facilities (than what Velocity offers) to display numbers correctly. Hence, Velocity users probably have a tendency to store numbers as strings and, of course, then, sometimes you want to convert the strings back to numbers, because you might want to, say, add them together or something. But all of that is just a consequence of Velocity's lameness in not addressing basic things like this. In general, when using a template language worth its salt, you shouldn't be converting strings into numbers. For the reasons I gave above, it's inherently problematic.

Again, what you need is a template language that is full-featured enough so that, in your data model, strings can be strings and numbers can be numbers basically, and you have the full facilities to display the numbers correctly according to local conventions, and as currencies or percent or in scientific notation or however you want. FreeMarker provides this.

Dejan Bosanac
2007-03-22 04:29:11
Hi Jonathan,

I agree with you that Freemarker is superior to Velocity in many ways. But also, I think that for sake of all projects that already using Velocity, it is important to keep improving Velocity, and that's why this upgrade is important.

As far as string to number conversion goes, I don't see why it is so dubious. Many script languages sorted this out quite well (look PHP for example, or Unix strtod command). I don't say that it should work for all possible cases, but could make life easier for developers in simple cases. Anyhow, it is just a wish on a wish-list, not a functionality one can't live without.

Cheers and keep up the good work.

Will Glass-Husain
2007-03-22 20:26:15

Thanks for the kind words. We're excited too. I think you captured the spirit of this release. We tried to fix all the outstanding bugs and as many of the syntax inconsistencies as we could while maintaining drop-in backwards compatibility. We also improved the ease of integrating with other applications with better logging, error reporting, and scalability. It's been a long time but we've got a great user community that encouraged us to finish up.

Quick side note: You can test for null with if using this syntax
it exists!
it's null!

The string to number casting is an interesting but controversial idea. We've discussed this in the past. I like it too but our larger community has reservations.

Henning Schmiedehausen
2007-03-23 00:54:38
I've added your comments / wishlist as VELOCITY-531. We are trying to incorporate any feedback into our development, thank you for pointing out your sore points. I was not aware that the #break statement is a bigger issue for users.
Matthijs Lambooy
2007-03-23 05:39:21
For us velocity is a perfect engine simply because it is a simpler, more lightweight tool than Freemarker. We are very pleased with the new release 1.5 !!!
Jonathan Revusky
2007-03-23 13:26:15
Gee, Will, if you actually believed that transparently coercing strings into numbers was a good idea, you should never have introduced the + operator for concatenating strings.

Now, if you were to coerce the strings into numbers, what is "123" + 123, the string "123123" or the number 246? Now, you could set some arbitrary rules for what happens, like maybe it would matter which order they are in or something, but surely, you see, it would lead to very error-prone sorts of situations. So, now that you overloaded the + to mean string concatenation, it looks to me like you've cut off the automatic string to number coercion idea anyway. Just as well.... (You can thank for me telling you this, but the good lord did put a brain between your ears so that you could think about this and realize it for yourself.)

But, look, really, at some point, there has to be progress in a field and "controversial" ideas cannot remain controversial indefinitely. For example, obviously, a lot of people do need to work with decimal numbers in a template and that a template language should have this had to stop being "controversial", because actual praxis of people out there using the tool tells you this.

IOW, at some point, people debate, they grapple with the ideas and there is closure, and that is how progress occurs. Or are we going to be stuck in a time warp where it is still 2001 or 2002 and we don't know certain things. And in that vein, should one release 2002 or 2001 vintage technology with this tone of "excitement"?

P.S. Dejan, I don't care whether PHP does this or not any more than I care that BASIC and FORTRAN and C allow unstructured GOTO statements.

P.P.S. Yeah, Henning, add that one to your Velocity Roadmap. (LOL)

Jonathan Revusky
2007-03-23 13:44:56

The issue of simplicity that you bring up cuts various ways. Probably, if you use FreeMarker to do exactly the things you would do in Velocity, it is not more complex. The presence of extra functionality, on the other hand, has the potential of simplifying your work considerably, since things that are available via built-in functionality in FM require extensive hacking in Velocity to get the same result. Just consider things like the localized display of numbers, times, dates...

At one point I wrote an essay on the FreeMarker blog that relates to the whole simplicity issue and that is here:

On the basis of my thinking, as expressed in the article linked above, I have serious doubts that Velocity is really a serious candidate for large-scale web application development. The main reason for this (not the only one) is the deficiencies in its macro system.

It is unlikely that this is going to be addressed because it would likely require something like a full rewrite of the entire thing, and I don't see anybody undertaking a task of that scale. Besides, anybody who needs that functionality could just use FreeMarker.

Jonathan Revusky
2007-03-23 14:48:38
Dejan, you state that it is important to keep improving Velocity because of the existing projects that use it.

I have certain comments about that.

The main reason that legacy systems, technologies that most people think (and openly recognize) as obsolete, survive seemingly endlessly is that there are so many existing systems that it would not be feasible to port. There are millions of existing lines of COBOL, FORTRAN, and RPG and it is simply not practical to rewrite it all in more modern languages. (Aside from the "if it works, don't fix it" common-sense homily.)

It is not just the cost of porting all that code, mind you, but also retraining people to use Java or some more recent language is costly and even risky.

A similar case for maintaining Velocity is hard to make, since, as best I can determine, the cost of migrating from Velocity to another template engine such as FreeMarker, say, is fairly trivial. For example, when Max Anderson decided to switch the Hibernate-tools project over from Velocity to FreeMarker, I believe that it took him less than 2 days. This is probably par for the course.

I would also conjecture that a front-end coder used to mucking with Velocity templates, given a 3x5 index card, say, of the equivalent constructs in FreeMarker, could be happily and comfortably hacking FreeMarker templates, in, oh.... a few hours, I'd say.

So the cost of transition of the legacy languages like COBOL and such is simply not present. BTW (and this is really just off-topic chit-chat), I was kind of surprised to look at Wikipedia and see that COBOL was updated as recently as 2002. (There is such a thing as object-oriented COBOL, apparently!!!) There is a FORTRAN 2008 spec coming, and IBM put out a revision to RPG IV as recently as 2001.

But anyway, these dinosaurs refuse to die because of the huge investment in codebases and that it is simply not practical to switch.

Now, on the other hand, I grant that some people may want to keep using Velocity, and that maintaining it for the sake of existing users who don't want to switch does nobody any harm, independently of how uncompetitive the tool currently is. But there is one caveat to that. I think you must be clear that this is what you're doing. IBM, as much as they may support existing COBOL or RPG users with new versions, do not encourage people to build new systems with these tools, and actually, they actively encourage people to migrate to Java.

By analogy, if the goal of releasing a new version of Velocity is to service existing Velocity users, in the full knowledge that the tool is not removely competitive in its space, then this really has to be made clear.

The problem I see is in presenting obsolete technology as if it really was cutting edge and encouraging people to use it when much better alternatives are available. ASF is a non-profit entity, after all. Should it be advocating that people use whatever technology simply because it is from ASF? Or should it be because it really is, in their view, a valid option, competitive with other alternatives in its space?

I think that some question of responsible behavior collectively comes into play here. After all, projects from ASF have a significant visibility/marketing advantage. Frankly, it does seem almost as if there was a tacit agreement on sites like OReilly or theserverside, to treat anything that comes from ASF as necessarily newsworthy and having great merit.

For whatever sociological reasons (it resembles the emperor's new clothes parable really) they would be very reluctant to say straight-out that the new release of Velocity does not bring it up to being even remotely competitive in its application space. This is a pity because it would serve your readers much better to provide the unvarnished truth about such matters.

Dejan Bosanac
2007-03-24 11:00:27
Jonathan, I understand why are you so passionate about Freemarker, but I think that you are overreacting a bit. I meet a lot of people, with different histories of their projects, different skills in their development teams, etc... In such environment diversity of technologies (and implementations) to choose from is only a positive thing. Claiming that only one implementation should exist and bashing all others (technologies and projects) is the easiest way, but not really helpful in real life. Cheers.
A. Observer
2007-03-25 01:12:46
I don't think anybody said that "there should only be one implementation". Obviously it is better if people have choices.

Just consider the situation when somebody goes into an electronics store to buy a digital camera or some other gadget. They are faced with a huge array of choices. That there is such technical competition going on with different companies trying to produce a more compelling product benefits the consumer.

Now let's consider the case of model of camera from 5 years ago. If something like that is being sold, it is likely to be in the bargain bin, practically being given away. And it is pretty plainly clear that the product is obsolete. A store customer who is sold a 5-year-old model because a salesperson (responsible for informing him) presents it as new technology would have every right to be quite annoyed later.

If, when the salesman is showing the obsolete camera to an uninformed customer, somebody comes by and tells the customer that the model is 5 years out of date, is that person guilty of "bashing"?

People benefit from variety, from choices, but, as in the digital camera case, where you have various companies competing with cutting edge innovative technologies. There is not that much value in having choice when the choice consists of the ability to select an obsolete, superseded model, because nobody clearly informs you that the technology is obsolete.