velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: Features
Date Sat, 11 Mar 2006 15:16:10 GMT
jian chen wrote:
> Hi, Jonathan,
> I am a bit sad to see that the Velocity project hasn't been that active
> these days, particularly with the much needed enhancements still pending.
> However, I just don't like FreeMarker for the following major reasons:
> 1) FreeMarker tags look similar as html tags.

While it is true that FreeMarker directives are (by default) delimited 
by angle brackets, like HTML tags, I find it hard to believe that there 
is any real-world problem with people confusing something like:

<#list users as user>...</#list>

with regular HTML tags. Especially, if you make use of syntax 
highlighting to highlight <#...> and </#...> strings in a separate color.

That said, it's no longer an issue. FreeMarker now offers an alternative 
square bracket syntax like:

[#list users as user]....[/#list]

> 2) Too much feature in FreeMarker. The template engine language should be
> succinct. Otherwise, it might give people too much flexibility in
> templating.

Well, the fact is that we can only judge by what feedback we have. And 
the truth is that we simply do not get feedback where people are 
complaining about FreeMarker's excessive flexibility or that the tool 
has too many features. Actually, quite the opposite. If you google 
around looking for blog articles that contrast FreeMarker and Velocity, 
you will find many people who have switched from Velocity to FreeMarker 
because they found the latter to be more flexible, and also because it 
has features they need that were missing in Velocity. I do not recall 
ever seeing a blog entry in which someone switched from FreeMarker to 
Velocity because the latter had less (!!!???) functionality. Actually, I 
haven't found any blog entries where people mention switching from 
FreeMarker to Velocity period. It seems that all the movement is in the 
other direction.

Now, it is probably true that many FreeMarker users -- even most of them 
-- do not need all the functionality present in FreeMarker. They would 
be fine with just a subset. The problem is that this subset varies 
between users. The extra features in FreeMarker were all added because 
there was some evidence that some people actually needed them.

Again, we get no feedback of people complaining that FreeMarker is too 
powerful or flexible. On the other hand, if you look at the Velocity 
users list, you will see plenty of user comments which boil down to 
criticisms of missing features or inflexibilities. Just judging by this, 
it seems that the lack of key features and flexibility in Velocity 
causes far more inconvenience to Velocity users than an "excess" of 
functionality or features causes FreeMarker users.

> I would hope to have a better version of Velocity though, with the bug fixes
> and correct feature enhancements.

The problem is that feature enhancements that you consider necessary, 
other users might consider to be superfluous. And vice versa. If 
Velocity starts moving forward and incorporating features that users 
have been requesting (often for years) it will probably end up having 
plenty of features that you (and other people) don't need. But again, I 
think that, in practice, a tool having extra features you don't need is 
less of a problem than it missing key features that you do need.

Jonathan Revusky
lead developer, FreeMarker project,

> Jian
> Lead Developer, Seattle Lighting
> On 3/10/06, Jonathan Revusky <> wrote:
>>Jurica Viskovic wrote:
>>>Will , thanks!
>>>Last night i looked at source to see how
>>>to simply implement those new features, but
>>>it seems it will not be as easy as i thought.
>>The fact is that if nobody even gives you any pointers as to where to
>>look, where the crucial points in the code are, it's not generally going
>>to be easy. Some people are surely better at this than others, but I
>>personally find it very hard to get into an unfamiliar codebase and
>>understand the "mind" behind it.
>>I think it's only fair to tell you and anybody else interested in having
>>macros work this way, that this is already available in FreeMarker. For
>>example, if I define a macro as follows:
>><#macro foo bar baz="some default value">
>>    ...
>>it can be invoked with either one or two arguments. The baz argument
>>reverts to the default value when it is invoked with just one argument.
>>Macros with can be invoked with the parameters by name, as in:
>><@foo bar="arg1" baz="arg2"/>
>>If I listed all the other other goodies in FreeMarker's macro system
>>that are not present in Velocity, this message would get quite long. See:
>>These features have been present in FreeMarker for 3 years or more and
>>many people use this stuff in production and it is highly stress tested.
>>An existing mature tool that already has the features you want is likley
>>to be a better technical solution.
>>Jonathan Revusky
>>lead developer, FreeMarker project,
>>>Anyway i will forward this discussion on developers
>>>mailing list.
>>>Regards, jure
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

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

View raw message