velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <revu...@wanadoo.es>
Subject Re: The Guardian website moves to Velocity
Date Fri, 11 May 2007 11:31:52 GMT
Malcolm Edgar wrote:
> Sorry this was flame bait.

Malcolm, I just reread the message I posted and that is quoted below. I 
don't know on what grounds you are saying that it is a "flame" or "flame 
bait". People simply pointing out things that you don't like them 
pointing out is not what is meant by "flaming" or "trolling" or whatever 
loaded term you might throw into the conversation.

Any serious discussion about creating (in the words of Chris Towson) a 
complex, modular system would lead to the observation that VTL lacks 
basic facilities for supporting modularity.

Now, what I'm going to say now may veer into flame territory. The things 
I'm going to say are not politically correct, but I'm satified that 
they're accurate, and also I say them in good faith:

Malcolm, I think everybody (at least who pays attention to this) knows 
that you desperately want to get in on the ASF thing. You want to be 
able to call your Click framework "Apache Click" or something like that, 
because you believe (probably correctly) that you'll have 10 times as 
many users if you can call it Apache Click and have it be hosted on 
apache.org.

That's all fine, I guess. I understand it perfectly well. How many web 
app frameworks are there out there? Geez, god only knows. So how do you 
get anybody to pay any attention to your framework? It's tough, I know. 
One way to really jump-start things would be to get in on ASF. But how 
much are you willing to compromise your integrity to achieve the above goal?

I mean, trying to shut down a legitimate conversation about components 
and modularity (or whatever the topic) on the grounds of it being flame 
bait is ultimately ridiculous. The reason, you see, is that this would 
ultimately preclude any serious conversation. Really, it would, because 
any serious conversation about templating issues will tend to cast 
Velocity in a poor light, because the tool really does lack basic 
features that users of competing tools take for granted. That is 
precisely why, when you google around, you see all kind of commentary 
about switching from Velocity to FreeMarker, say, and nobody ever 
switching in the opposite direction.

Broadly speaking, there is a state of the art in a field. If you more or 
less abandon development for a period of 5 years, you will not have 
something that is competitive with the state of the art.

The other striking thing about all of this is that you are even willing 
to devalue your own pet project significantly to further your aims. I 
mean, you want to convey the idea that there is some greater connection 
or linkage between Velocity and Click than there really is. Typically 
web app frameworks broadly similar to Click that use a template engine 
for the view offer the developer a choice of various view tools, since 
it is trivially simple to have an abstraction layer such that the 
developer can choose. Obviously, letting people choose between Velocity 
and FreeMarker would make Click a superior tool to only letting them use 
Velocity. I even happened to notice that one of your users, Huy Do, 
specifically requested FreeMarker support, and you didn't add it in. 
This whole discussion:

http://article.gmane.org/gmane.comp.web.click.devel/830

You can correct me if I'm wrong, but my honest suspicion is that, 
basically, you know that if you presented Velocity and FreeMarker as 
options on an equal footing to use with Click, in short order, most of 
your users would use FreeMarker. Then that would sort of kill your game 
plan of representing that Click and Velocity actually have anything to 
do with one another -- and that's your foot in the door for getting in 
on the ASF thing, the Velocity people "mentoring" you and so on.

The above is a bit flamey, but I think it's accurate. You're probaboly a 
nice guy and I don't really have anything against you. But I do find all 
your behavior in this kind of cringeworthy.

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/

> 
> cheers Malcolm
> 
> On 5/11/07, Jonathan Revusky <revusky@wanadoo.es> wrote:
> 
>> Townson, Chris wrote:
>> > http://niksilver.com/2007/05/10/guardian-unlimiteds-new-look-s
>> >
>> > 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:
>>
>> http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html 
>>
>>
>> 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:
>>
>> http://jroller.com/page/raible?entry=freemarker_vs_velocity
>>
>> I'm referring to this part specifically, where Ken says:
>>
>> <QUOTE>
>> 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.
>>
>> </QUOTE>
>>
>> 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, http://freemarker.org/
>>
>> >
>> > 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: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org


Mime
View raw message