velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: The Guardian website moves to Velocity
Date Fri, 11 May 2007 10:13:02 GMT
Townson, Chris wrote:
> thought this might interest members of this list, if you haven't already seen it.
> It would be interesting to know a little more about the tools they built:
> I know that we at Nature have been working towards a "component"-based system 

I'm actually quite interested in this sort of thing and I wrote a blog 
article about it. You might or might not find it interesting. Other 
people might (or might not) find it interesting as well:

There, you see that, I make no bones about what I think regarding 
Velocity. It definitely seems to me that VTL is lacking certain basic 
features that you would need to build reusable components. The macro 
system is just too deficient.

That's not just my opinion. For example, look at the comments by Ken 
Egervari in this blog entry:

I'm referring to this part specifically, where Ken says:

However, I've been doing some pretty complex stuff in the view. Now, I 
don't mean I'm putting business logic in there - that's not it. I've 
just been making massive amounts of investment in macro libraries and I 
build higher-level marcos for all sorts of application-specific 
presentation reuse. However, Velocity just isn't any good at doing this 
- and I'm not even talking about large scale applications, I'm talking 
about a small to medium-sized but featureful project a competent 
developer can write in a few weeks.

I think I've hit the capabilities of Velocity and I've been stretching 
it quite a bit. Without named/optional parameters or even basic macro 
overloading, I just can't build complex views and avoid duplication at 
the same time very easily. It's like a pain in the ass just to add an 
option column, button or sub-screen for a specific listing that uses the 
general listing macro and so on. I have all kinds of cases where I have 
to do functional-oriented type checking and it's inexcusable.

Freemarker seems like the way to go. While it's probably more difficult, 
the end result looks to be more like html. When I saw features for 
unordered named, optional parameters and nested content, I realized that 
these features alone make it better than Velocity because they just 
aren't "nice" features, the are just down-right required.


The above comments were made several years ago, and I do not see any 
forward movement in this project in terms of addressing the deficiencies 
that Ken is mentioning there.

 >(which seems to be what they've developed at The Guardian) for a 
little while
 >now and are shortly to go live with a Spring-based system for formalizing
> the management of the design and templating of large, complex, modular 
 > sites using Velocity.

Large, complex, modular sites using Velocity, eh? I suppose it's 
possible. But really, you know, when you can't even #parse a set of 
commonly used macros in a separate file, and there's no notion of 
scoping or namespaces whatsoever, so that any variable defined locally 
in a macro potentially clobbers variables defined elsewhere -- to rely 
on that kind of tool to build something complex and modular, does not 
seem like a very good technical decision. The tool simply lacks 
necessary things for modularity.

> There might be some common ground covered between us and The Guardian here 
 > which could be fed back into the Velocity project itself, perhaps?

Well, historically, lobbying Velocity developers for features that you 
need has not been a very fruitful path. I won't go on further about 
that, but surely you can perceive that, even bending over backwards to 
be generous and all, you can't describe this as a very dynamic 
environment, can you?

Jonathan Revusky
lead developer, FreeMarker project,

> Best,
> Chris
> ********************************************************************************   
> DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
> not the original intended recipient. If you have received this e-mail in error
> please inform the sender and delete it from your mailbox or any other storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
> liability for any statements made which are clearly the sender's own and not
> expressly made on behalf of Macmillan Publishers Limited or one of its agents.
> Please note that neither Macmillan Publishers Limited nor any of its agents
> accept any responsibility for viruses that may be contained in this e-mail or
> its attachments and it is your responsibility to scan the e-mail and 
> attachments (if any). No contracts may be concluded on behalf of Macmillan 
> Publishers Limited or its agents by means of e-mail communication. Macmillan 
> Publishers Limited Registered in England and Wales with registered number 785998 
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
> ********************************************************************************

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message