Jonathan Revusky said: ...
As for the Velocity Tools subproject, my take on things is that it largely came into existence as a set of workarounds for limitations that existed in the core template engine. Velocity development came to a standstill at least a year ago, and probably things that normally might have been added to Velocity itself were put in a tools project.
You describe the project as "a set of workarounds for limitations." This is not
entirely true, and where it is in a sense true, otherwise would phrase it with
more grace.
<sigh>
I infer from your roundabout prose above that my characterization was broadly true. :-)
Please recall that some of these "limitations" in velocity are very
intentional and have in the past been vigorously defended as being "the right
way."
Frankly, at this stage in the history of the project, how seriously is this whole "MVC minimalist" thing to be taken? We have a situation where the developers in the main Velocity project, to all intents and purposes, have not committed any code for a year. It is not simply that they have not added new features. They have not fixed any bugs, there have been no improvements in the documentation. They have simply done nothing. There is an electronic record that one can consult of CVS commits that shows this.
It is one thing to be conservative about adding bloat, but can that really justify what we observe -- that absolutely nothing has happened for a year? Can this be "the right way"?
I am sorry to express this cynicism, but I suspect that I am simply expressing what many observers think and do not openly express: the "MVC purism" and "minimalist elegance" rhetoric is largely a post-facto rationalization for the fact that no development is taking place.
Whether they are or not is largely beside the point here; we can all agree that some people don't care and still want to do things "the wrong way."
Well, my casual observation on this list is that, the minute somebody wants to do something that is not supported by Velocity, various people chime in and say the person is not following a proper MVC architecture. Like, somebody wants to be able to add two decimal numbers together, they're not doing proper MVC. Isn't that kind of thing getting a little bit stale?
And sometimes they (and "they" includes me) have good reason for that. As such, there is demand for such things as the MathTool and RenderTool (probably the two most "workaround-ish" in the project). So, we are simply meeting that demand without offending the MVC purists.
Well, not everybody enjoys my presence here (though I'm sure some people do!) or the comments I make, but I am scrupulously honest and I clearly know what I am talking about in terms of this application space. You can look at FreeMarker and know that I am lead on that project and draw that conclusion. So, when I say that *I* don't take this "MVC purism" very seriously (i.e. I think it's something of a bad joke at this point) you can assume that I'm simply expressing my honest reaction.
What I really wonder is this: Do you guys really take this "MVC purism" line that seriously yourselves? Or is it really just some kind of sacred cow that keeps getting trotted out, but really, at this point, ought to be put to rest?
I perceive a situation where people are simply afraid to say that the emperor is wearing no clothes. Surely plenty of people perceive it.
That said, most of velocity-tools is of an entirely different purpose. It provides support for developing web applications with velocity following a Pull-MVC paradigm. In particular, the project also supports integration with the Struts framework. Most of these things would *never* (none of this "normally might otherwise" stuff) be added to velocity's core, because velocity is not just for web development. In fact, some among us believe that even the VelocityServlet should be yanked from the core in favor of the tools project.
Well, the fact remains that, as a practical matter, usage of tools like Velocity or FreeMarker (or WebMacro for that matter) is dominated by the web space. Just how inappropriate is it to put things that are specifically for web app development in the main distribution? I can tell you that FreeMarker is also used outside the web space. However, I don't think that having more out-of-the-box functionality for web stuff in the main, default distribution actually *inconveniences* anybody who wants to use FM for non-web applications. And even if it did, we would be inconveniencing a relatively small minority in order to make life easier for the vast majority. And that would be justifiable, would it not?
So, though I have not been involved from the outset, it is my understanding that *that* was the primary reason this project began. And certainly, web application support has been the driving force since I got involved here.
Well, as lead on the FreeMarker project, I would not see any particular justification for creating a separate "tools" subproject of FreeMarker for dealing specifically with the web space. Particularly not when I know full well that over 90% of usage is in the web space. Usage in web apps does not strike me as a sort of specialized application domain that would suggest the creation of a separate subproject. And even if I did think that creating a separate subproject with a separate CVS module and separate release cycles was warranted, I would see no justification for the members of that subproject to be in some completely different rubric as regards their committing rights and so on -- that they can only commit code in some kind of "fm-tools ghetto" as it were...
It does not strike me as a felicitous situation. It looks to me like there is some kind of suboptimal workaround there, people making the best of a bad situation.
Best Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html FreeMarker 2.3pre4 is out!
Nathan Bubna [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
