I agree with Nathan. Funny thing is that I have build serveral webapps the purist way over the years, but found that a lot of times it actually made thing less clear. For example, if you look at portal-like sites, where you have blocks of content with read only information (like breaking news etc.), it becomes a pain to allways have to go the 'clean' MCV way and prepare all the objects the view might want to use (though the original pattern has nothing against accessing the model right from the view). Especially in portal-like situations, a lot of the view components do not relate to each other at all. I know I can do stuff like this with something like Sitemesh, but I personally don't like sitemesh too much and it would add *yet* another layer to configure etc.
Amongst others, I have tools to do simple Hibernate queries, a tool that mimics some of the JSTL tags like the core import tag (try including a JSP in a velocity template now...) and the string tags, and a application specific tool that translates logical names to links to resources. Sure all those things can be done in other ways, and actually I think the ability to include custom tags is a cool one (though I never guessed 'purist' would agree to that), but the Tool project makes it damn easy to implement. So, in I do not use the Tool project as a set of workarounds at all; I use it deliberately, and think my apps are better structured than before using pull functionality. Eelco Hillenius ----- Original Message ----- From: "Nathan Bubna" <[EMAIL PROTECTED]> To: "Velocity Developers List" <[EMAIL PROTECTED]> Sent: Sunday, June 15, 2003 5:05 PM Subject: Re: JavaCC open sourced on dev.java.net > 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. 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." 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." > 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. > > 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. > > 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. > > Nathan Bubna > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > 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]
