Jonathan,

Basic common sense? Based on your long posts on Velocity forum, I think I can 
ask you if you have some common sense.

If you really think Velocity is a dinosaur, you could let him die(with some 
respect if you say it meant something 7 years ago).If you think FreeMarker is 
the brightest start above the horizon, you should let the users to discover 
FreeMarker by themselves. If there is somebody out there looking for a template 
engine and he's going to stop to Velocity without evaluation other projects, 
it's his fault if fails(if he finally realized Velocity doesn't have all the 
features he needs). It's his bad, not because Velocity is a *junk*, is just 
because he didn't took some time to evaluate at least 2 projects. Even if you 
fail to choose the right project(the reason doesn't matter), it is still useful 
for you, everybody learns from mistakes. Even with Velocity, most of the 
problems will be on your project side. Those missing feature will not block you 
form releasing your project, I can tell you that.

If you search after "java template engine" in Google, you'll find Velocity and 
FreeMarker, so it would be really hard to miss FreeMarker and choose 
Velocity(if you're afraid of that). Some people could use Velocity even if it 
lacks some features just because of the syntax, or just some other "stupid" 
reasons.

This is not about coding style, features and not even performance(even if it is 
an important aspect). Even if you do a code review, some similar rules applies 
: review the code and not the person(project), ask for the reason why the code 
is as it is, ask before accuse, etc, etc. 

I'm not going to continue arguing with you why you shouldn't behave like this, 
I think if you didn't got it until now it is too late to try now. I will not be 
one who will "turn you to the light" :), that's my personal feeling. My 
personal advice is let the community to grow around you and let others live 
with their projects. In the end, everybody will win. 

Best wishes,
Adrian Tarau.

PS. It was not my intention to reveal your private message, it was more an 
"automatic" reaction to the words "project", "junk", "mine is better" based on 
my personal experience. My apologies to you. 
    If you really want to help somebody(who reached the end of the road with 
Velocity) just reply with a link to FreeMarker and let the user decide, before 
you will write long(or short) paragraphs about ... you know ... junk. 



-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Revusky
Sent: Saturday, March 08, 2008 4:55 PM
To: dev@velocity.apache.org
Subject: Re: Call a velocity macro

Adrian Tarau wrote:
> Hello Jonathan,
> 
> /"Well, in general, once you want to do anything moderately complex with 
> velocimacros, the thing breaks because it's.... *junk.* :-)"/
> 
> It's not nice to say about a different library(a "competitor") "it's 
> junk", even if the library is not as good as yours(I'm not sure if you a 
> commiter or just a user of FreeMarker).

What's not nice and a clear violation of nettiquette, as well as basic 
common sense, is to respond to a private message (one that was clearly 
meant to be private) in a public forum.

Well... okay, I guess you just don't know that. If you don't know, you 
don't know. However, it stands to reason that if you don't know that, 
there are may be plenty of other basic things you don't know.

So, first of all, there is no onus on me, particularly in a private 
note, to pretend that I think that Velocity is anything other than 
obsolete junk.

> I agree, velocity has some weak parts, but this doesn't mean is "junk". 

Well, that's debatable. There's no clear definition of what "junk" 
means. A key characteristic of junk, at least most junk, is that, at one 
point in the past, it was something of value. Some 386 or 486-based PC 
lying around in someone's basement is junk, but at some point in the 
past, it was a highly valued state of the art piece of equipment.

Getting back to niceness, since you accuse me of not being nice, one 
thing that wouldn't be nice would be to sell that old 386 or 486 to 
someone who had no knowledge of computers and represent that it was 
something that was state of the art and so on.

> I'm not pro Velocity and against FreeMarker of vice versa, and I am glad 
> for the existence of projects like Velocity or FreeMarker(all the Apache 
> projects, etc).

Besides nettiquette, a whole aspect of this you don't seem to understand 
is that projects are really only useful if they are approximately 
competitive with the state of the art in their space. I could write a 
simple text editor or database this weekend and start announcing it on 
all the appropriate forums. However, it would be a complete and utter 
waste of time. Not only would I be wasting my own time (no big deal) but 
I would trying to get people to waste their time as well. When things 
like emacs and jedit exist, nothing I could write in short order would 
be remotely of any interest to anybody. Look, it takes a certain ego and 
nerve to announce your work to fellow professionals on places like 
freshmeat.net and theserverside.com etcetera. To do this takes a certain 
ego. You have to believe that, what with all the things out there that, 
people really should take the time to look at what you've done. It has 
to be broadly competitive with the state of the art.

> 
> So let's play nice...You can post articles about "FreeMarker is better 
> that Velocity" but do it with professionalism.

The whole idea that I, in the name of "professionalism" have to pretend 
that the emperor is wearing any clothes, particularly in a private note, 
is just absurd. Even in public there is no particular need for me to do 
so. You may have noticed that people who review movies online and 
elsewhere do not feel obliged to tell you that every movie that comes 
out is actually good. And likewise, I am under no obligation to say that 
every software tool out there is good. I don't consider Apache Velocity 
to be something of high quality, to say the least. Not only is it 
lacking in features that really should be considered by now to be basic 
to templating in the web space, it embodies numerous first order 
mistakes in design and implementation that, in over 7 years of 
existence, nobody has put in the effort to remedy.

In my considered opinion, it is naive and misguided to feel gratitude to 
ASF for something like Velocity. I believe that if Apache were run in a 
way that really reflects its charter, to be of benefit to the overall 
developer community, something in the state of Velocity would be labeled 
as abandonware. Basically, the maintainers would have been put on notice 
that they had to either get the thing in a state that it is 
approximately competitive in its space, or the front page of the project 
would say something like "Hi, I'm an abandoned piece of software. If you 
want to adopt me, here is the procedure to do so." If Velocity and the 
other many projects in the same state were labelled that way, it would 
be of much greater benefit to the larger community. First of all, people 
would be dissuaded from investing energy into something that is obsolete 
and unmaintained. Also, people who actually do want to do the work of 
maintaining the project would have a chance to do so.

But alas, obviously this is not the case. And specifically, that is why 
so many software projects out there have initially used Velocity (based 
on the belief that it was approximately competitive and being 
maintained) and later had to switch to another tool, typically 
FreeMarker. Some of the best known open source projects in the java 
world went this route -- Hibernate, Netbeans, WebWork/Struts 2. 
Obviously very many valuable developer man-hours were squandered this 
way because Velocity was advertised as an active cutting edge project 
when it wasn't.

I document this in a blog entry. See:

http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html

> 
> PS . My framework(yet another java framework??? :) ) allows me to choose 
> between any template engine without modify any Java code so it is 
> transparent for me in general. This situation with calling dynamically a 
> macro is the first exception in years, usually I have anything I need in 
> Velocity, I don't need to think about another library(not that the 
> Velocity is the only good template engine, but I got used with it).

What you are saying is a big nonsequitir really. If I only used the 386 
or 486 computer I mentioned above  (along with applications of that 
vintage) I would probably think it was great, assuming that I had no 
exposure to the current state of the art in personal computing. Sure, 
it's probably true that you have not felt that features were missing 
from Velocity. Similarly people who have only used procedural 
programming languages like C or FORTRAN or whatever, may feel that they 
are not missing any of the features in more modern object-oriented 
languages. However, once they do make the migration, they realize that 
there are many far more elegant maintainable solutions to problems that 
are now easy to implement that were not really possible before. In any 
case, we see from many of these threads that other people are feeling 
the lack of basic templating features -- macros with an associated 
block, optional/default parameters, and so on.

In any case, I imagine you (and some other people) won't be happy about 
this note I have written. However, you do seem to be suffering from some 
very basic misconceptions about.... well... a whole bunch of things. I 
write this on the forum, not just because you replied to me here, but 
also because surely other people are suffering from similar 
misconceptions, and if you don't take what I'm saying to heart, maybe 
somebody will, so I won't be just venting. It will have served some purpose.

Jonathan Revusky
--
lead developer, FreeMarker project http://freemarker.org
Velocity or FreeMarker: Looking at 5 Years of Practical Experience
http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html


> 
> 
> Jonathan Revusky wrote:
>> Adrian Tarau wrote:
>>> I've always used #if to implement the 'switch' but I think, even for 
>>> 3-4 conditions, the template will look cleaner.
>>>
>>> Instead of
>>>
>>> #if('renderLabel' == $macroToCall)
>>> #renderLabel($component)
>>> #elseif('renderInput' == $macroToCall)
>>> #renderInput($component)
>>> #elseif(...)
>>> ...
>>> #end
>>>
>>> we will have
>>>
>>> #call($macroToCall $component).
>>
>>
>> This kind of thing is trivial in FreeMarker. For example, suppose you 
>> had:
>>
>> <#assign macroHash = {'renderLabel' : labelMacro, 'renderInput' : 
>> renderMacro, .... >
>>
>> and then, supposing you have an action string, like suppose:
>>
>> [#assign action = 'renderLabel']
>>
>> then you could invoke the macro via:
>>
>> <@macroHash[action] component />
>>
>>
>> The thing is that macros in FreeMarker are variables, and can be in 
>> hashes or assigned to variables or whatever, and also the foo in 
>> <@foo/> to invoke the macro can be any arbitrary expression.
>>
>> So, for example, suppose the macro you want to invoke is in the string 
>> macroName, you could invoke it via:
>>
>> <@.vars[macroName] component/>
>>
>> (.vars is a special built-in hash that contains the variables 
>> available in the template and since macros are variables as well, 
>> .vars[macroName] is the macro with the name macroName and it can be 
>> invoked this way, or you could create a variable.
>>
>> <#assign myMacro = .vars[macroName]>
>>
>> and invoke it via:
>>
>> <@myMacro component/>
>> Right below this, Mr. Van Bergen mentions Anakia, which is an add-on 
>> to Velocity for processing XML. He neglects to mention that FreeMarker 
>> provides similar XML processing functionality (though the 
>> implementation is much more complete, since it supports XML 
>> namespaces, for example) as part of its core feature set. Declarative 
>> XML processing is supported in FreeMarker via the #visit and #recurse 
>> directives, which are core directives in the FreeMarker language. One 
>> would infer from what the article says that XML processing is a point 
>> in favor of Velocity, when, really, quite the opposite is the case. 
>> The XML processing functionality available for Velocity is add-ons 
>> like Anakia and DVSL that are basically abandonware, where the XML 
>> processing support in FreeMarker is a core part of the product, and is 
>> clearly supported.
>>
>> Well, in general, once you want to do anything moderately complex with 
>> velocimacros, the thing breaks because it's.... junk. :-)
>>
>> Here is a blog entry I wrote regarding some of this sort of thing:
>>
>> http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html
>>  
>>
>>
>> Jonathan Revusky
>> -- 
>> lead developer, FreeMarker project, http://freemarker.org/
>>
>>>
>>> In case of a value outside the 'domain' you will get an exception 
>>> "Macro not found ....".
>>>
>>> We could have even a directive which will simulate the switch default 
>>> branch.
>>>
>>> #callWithDefault($macroToCall $defaultMacro ....) - of course the 
>>> name should be shorter.
>>>
>>> Christopher Schultz wrote:
>>>> Adrian,
>>>>
>>>> Adrian Tarau wrote:
>>>>> I have the following problem : I would like to call a macro but the 
>>>>> macro
>>>>> name must be a variable.
>>>>
>>>> This is more of a question for the user's list, not the dev list. In 
>>>> the future, please post there.
>>>>
>>>>> Ex: instead of #renderLabel($component) to have #call("renderLabel"
>>>>> $component) - of course "renderLabel" can be any (existing) macro 
>>>>> name.
>>>>
>>>> How many possibilities can you have for $component? Are they 
>>>> unlimited, or constrained to maybe 5 possibilities? I'm wondering 
>>>> because you could easily do it like a switch:
>>>>
>>>> #if('renderLabel' == $macroToCall)
>>>> #renderLabel($component)
>>>> #elseif('renderInput' == $macroToCall)
>>>> #renderInput($component)
>>>> #elseif(...)
>>>> ...
>>>> #end
>>>>
>>>> -chris
>>>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to