velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Date Thu, 13 Oct 2005 14:21:09 GMT
Christoph Reck wrote:
> Hi Jonathan,
> since you are eager to understand how Velocity is progressing, you can
> see that Velocity is not a one-man-thing, but a team of lead developers
> and other contributors spending some of their time to test patches,
> implement requested features and to answer user questions on the
> mailing lists. One main goal seems to be the do-it-right and professionally
> (with a slower progress than in the main bread-and-butter jobs), as well
> as ensuring backward compatibility.

Though this is veering into a meta-discussion, I cannot help but make a 
few comments of the "meta" nature. When I read the above at first, I was 
naturally irritated. There is this level of insufferable pompous 
posturing -- "we are such professionals blah blah" -- that I find to be 
extremely provocative.

I initially perceived this as a form of aggression or provocation. And 
then, this lead me to wonder whether the intent, in fact, was to enrage 
me, and get me to say something immoderate in response. (And that, in 
turn, would give the yahoo elements here something to sink their teeth 

But actually, I don't think you're that Machiavellian. This kind of 
empty, pathetic posturing is probably just something reflexive at this 
point. It seems to be the norm in this community. Since you guys do seem 
to function in your own kind of crazy bubble, I guess you don't have a 
sense of just how preposterous it would seem to any outside observer. As 
such, you are casting yourself in a somewhat ridiculous light, and you 
might be doing yourself a favor to take that into consideration...

Anyway, all this stuff about what great professionals you are, in the 
context of basic features simply not being implemented, sort of begs the 
question. If the progress you are detailing about this whitespace issue 
is typical of the professionalism of this project, then maybe what you 
need is some unprofessionalism, then  maybe you could get some things 
done! :-)

> The fact that Velocity has a large user comunity lies on the simplyness
> and beauty of the approach. It is very useful as it is. Some enhancement
> would raise its usefullenss, and these are finding its way in, mostly
> in a BC form.

Well, Christoph, the above statements are entirely vacuous. The 
_approach_ of Velocity may well be "simple" and "beautiful", but not 
more so than any other template engine. The basic idea of a template 
engine is, in fact, simple.

Now, Velocity may well be "simple" in the sense that it lacks many 
features that a more powerful tool like FreeMarker has. However, to 
suggest that people performed a duly dilligent comparison of these tools 
and opted for Velocity because it is _lacking_ in various features does 
not really ring true. Do you believe this?

After all, it doesn't bear close scrutiny, since, if you just use 
FreeMarker in the exact same way that you would use Velocity -- not 
leveraging any more advanced features -- it is not any less simple than 
Velocity. Meanwhile, just look at the workarounds being proposed for 
Velocity's complete failure to handle the whitespace issue. This 
definitely does not make for simplicity.

Solutions involving underpowered tools for a job will typically be more 
complex than those that use an appropriate tool. The horrendous 
workaround for the whitespace issue that you admit that you use is just 
one such case.

> The proposal for the whitespace gobbling for structured templates was
> made by me in 2001. 

Hmm. Well, that is a while ago, seeing how 2006 is just round the 

Christoph, I cannot easily imagine that you are not at least somewhat 
disappointed by the lack of progress on this. However, you do not react 
in what I would consider a normal way. If you feel disappointment about 
this, you seem to be quite unwilling to express it. You seem to want to 
represent that this is completely normal...  "we're all fine 
professionals making sure to take the time to 'do it right'...."

Well, how much time is reasonable?

> The escence was finally taken up into an issue
> And the different approches and community requets where summarized
> in the wiki:
> With the scheduling features in Jira and Will having taken the lead,
> it has been scheduled for a 2.0 release when some non-BC formatting
> changes would be possible.

Well, isn't backward compatibility just being used here as a mantra to 
rationalize the fact that nothing has been done?

If the above referenced proposal is how whitespace *should* be handled 
by Velocity, even if the changes are not completely backward compatible, 
is this a reason to dawdle? I mean, whatever transitional cost has to be 
assumed at some point anyway, so why not bite the bullet sooner rather 
than later?

Also, the value of 100% backward compatibility in new versions can be 
overstated IMO. After all, a user always has a guaranteed way of having 
complete backward compatibility, which is not to upgrade their existing 
version. The existing version is useful as-is, as you point out above. 
Moreover, anybody totally paranoid about breaking existing code will be 
very slow to upgrade anyway.

> I also suggested that the parser should not gobble any whitespaces,
> and then add a postprocesor to the AST implementing the desired/configured
> gobbling schema!

This is, in fact, how I implemented it in FreeMarker. There is a routine 
that walks the parse tree after parsing and does the whitespace adjustment.

What is interesting here is that, with this disposition, there is no 
backward compatibility issue, since the post-processing of the AST can 
be optional. In FreeMarker 2.2.x, the whitespace stripping was a toggle 
you could turn on, and then in 2.3.x, it was on by default, and you had 
to explicitly turn it off.

By the way, here is something that could be of interest to you. You know 
how many complaints we got from users about the fact that FM (as of 2.3) 
was stripping all the extraneous whitespace by default?

Zero. Zilch. Nada.


Though it's theoretically not backward compatible, it would seem that 
nobody missed all that extra whitespace in the output anyway. So, if you 
want to benefit from the experience of our community (and why shouldn't 
you?) our experience suggests that the backward compatibility 
implications of this are, in fact, an ersatz issue.

> The implementation for such a change is far from trivial, being a rework
> of the parser, and will affect BC.

Yes, the implementation is far from trivial. I would know. You do 
realize that, of all the people who are involved in this thread, there 
is exactly one who has implemented this whitespace behavior in code. Me.

It was a bear to implement. Of course, as I said, our community also has 
the experience of whether the backward incompatibility that this entails 
is a problem in practice. I think it's safe to say that it is not.

> It is an open community, and anyone who is interested can jump in
> and supply a patch.
> Personally, if someone reworks the parser to be non-whitespace-gobbling,
> I would be eager to then provide the structured template gobbling
> implementation patch!

If somebody else does X, then you'll do Y.

Okay, but on this business of professionalism, is this level of 
attachment and sentimentality to tools really very professional? For 
several years now, there is another tool that has the whitespace 
behavior you want. Wouldn't a true "professional" just use that rather 
than insist on using something that does not have the feature he clearly 
needs, and, to all outward appearances, given the lack of action in 4 
years or more, may *never* have the feature in question.

I asked you whether you considered it somehow improper or unfair for me 
to tell people -- in the context of a thread on the subject here -- that 
FreeMarker has this whitespace removal behavior as described on your 
wiki. I reason that there is nothing improper or unfair about it. People 
with a professional attitude would surely be grateful that I inform them 
that a tool they may not have been aware of has the feature they need.

So, Christoph, do you consider it somehow improper for me to tell people 
that FreeMarker has the feature in question? (If you do, I would want to 
know on what grounds...)


Jonathan Revusky
lead developer, FreeMarker project,

> :) Christoph Reck
> Jonathan Revusky wrote:
>> Christoph Reck wrote:
>>> Hi,
>>> the whitespace issue has been debated quite a lot, and we have a
>>> consensus in this list that we will implement in the future a
>>> gobble-none and a gobble-structured form; 
>> That is interesting to hear, Christoph.
>> I'm still a bit vague on the details.
>> When did all this debate occur?
>> What is currently the status of implementing this? Has somebody been 
>> assigned ownership of the issue?
>> Is there some roadmap which says approximately when a future Velocity 
>> will have this? (I do not recall it being in the list of things to be 
>> in 1.5.)
>> <snip>
>>>> #if $(user.isAuthorized)#*
>>>>    *#Hello#*
>>>> *##else#*
>>>>    *#Good Bye#**
>>>> **##end
>>> that's what I'm doing sometimes now, and it's yuck to mainatin!
>> Well, I sympathize with that, it really seems terrible to me. OTOH, 
>> are you obliged to use Velocity for these purposes, company policy or 
>> something?
>> Because if not, obviously, obviously I know of one better alternative 
>> available. (Guess which one? ;-)) But there may be others. I have not 
>> done a survey of the template engine field recently.
>>>> But is this reasonable?
>>>> Again, the fact that it is possible to achieve precise control of 
>>>> whitespace is not the key point. It is that you want such control 
>>>> while having a reasonable, human-readable template. That is the 
>>>> raison d'ĂȘtre of templates really.
>>>> Okay, I guess no Revusky posting would be complete without a 
>>>> FreeMarker plug. The FreeMarker solution was to introduce whitespace 
>>>> trimming directives that are applied at parse-time.
>>>> So, in FreeMarker, you could write:
>>>> <#if user.isAuthorized>
>>>>     Hello<#t>
>>>> <#else>
>>>>     Good Bye<#t>
>>>> </#if>
>>> That is exactly in the line of:

>> Well, except that there is an important practical difference: this is 
>> the way FreeMarker actually works, has been working for the last 
>> couple of years at least. Meanwhile, you are pointing to a document 
>> that says: "wouldn't it be nice if Velocity worked this way?" It is a 
>> significant difference in particular when somebody needs this to be 
>> working today, not at some unspecified date in the future.
>> Earlier, I probably infuriated people here by saying that "if you talk 
>> the talk, you should walk the walk." But this issue seems like yet 
>> another case in point. If, in the Velocity community, for all the talk 
>> or debate, there is not the gumption to sit down and do the work of 
>> implementing badly needed functionality, and if, in our community, we 
>> have done the work of implementing the feature that many people need, 
>> why should I refrain from telling people this when they specifically 
>> query about this? Especially when many people who could benefit from 
>> our work may not be aware of it?
>> So, when I have said that if you guys talk the talk, you should walk 
>> the walk, you do see my point, don't you?
>> It seems fair to say that, at least for people who have no significant 
>> investment in Velocity, if they need or may need fine control of 
>> whitespace, they should look elsewhere.
>> Would you disagree with that, Christoph?
>> Regards,
>> Jonathan Revusky
>> -- 
>> lead developer, FreeMarker project,
>>>> The <#t> directives indicate that the opening and trailing 
>>>> whitespace on the line is to be gobbled, i.e. it is there to make 
>>>> the template human-readable. (There are also whitespace gobbling 
>>>> rules that say that the if else and the closing tag, since they 
>>>> occur solely on a line with no other whitespace output, gobble their 
>>>> opening and closing whitespace.)
>>>> [snip]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message