velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject RE: You make the decision
Date Mon, 05 Mar 2001 14:45:32 GMT
 From: David Esposito []

> Ok, I know this is going to bring on some flames ... but whatever ...

Flames are good - given your current energy crisis and price of heating oil
here in the northeast, I need some additional heat.... :)

> The article brings up some pretty interesting points and certainly
> illustrates a lot of the reasons why we ultimately decided to
> use Velocity for our project. But it is certainly not a resource for
> someone that is trying to "make the decision" ... It doesn't even come
> to illustrating  any of the downsides of using Velocity (or any true MVC
> architecture) ... a very one-sided article by almost anyone's standards

To start off,  keep in mind that I don't speak for Jon - he is the author.
I have opinions about what YMTD is saying, but it is only my interpretation.

I think your observation isn't off base, but I don't think that YMTD was
meant to cover really cover both sides like that.  I think that Jon was very
honest in describing what he was setting out to do - to "compare what it is
like to do the job with each of the tools.", and as it is a 'living
document' of sorts, I am sure that he would be happy to address and debate
any valid concerns you have.  If there is a quality about Jon that I think
won't be debated, it is that he is honest, open, and truly cares about what
he works on.

 I would think it interesting to get an argument from the 'other side' - the
how the disadvantages of Velocity or template engines in general (WM?) are
solved by JSP.   Maybe we should invite Craig McClanahan or another to argue
the other side - either as an answer to YMTD or a making the case
independantly - then maybe someone like yourself could try to bring the two
together from a 'user' point of view.

> One particular peeve I have about the article is its lack of
> illustrating
> one point ... prototyping an application ... One of the
> reasons that Cold
> Fusion and JSP have gained such market share is because the
> first person to
> take a whack at a prototype for an application is often the
> web designer ...
> Non-developers can build screen shots and even demonstrate some basic
> functionality by using a few <CFOUTPUT> or <%= %> tags and a
> few HREF links
> ... On the other hand, building a prototype by a non-developer using
> Velocity is not possible. Every page must be constructed
> using a back-end
> servlet ... This means that the prototype and the production
> app must be two
> independent projects (unless you want to allocate a developer
> to build a
> servlet and modify the deployment descriptor for the web app
> for each page
> that the designer wants to add)...

I think that when you combine Velocity with  an application 'framework' this
issue isn't as important.  By framework, I mean something as elaborate as
Turbine, or as simple as a 'generic' servlet that loads the context with a
set of objects specified in a configuration file - towards the Pull Model,
maybe.  Something as simple as a config file for the servlet containing
name/class  pairs to stuff into the context to be made available to the
designer, and specify the template to be rendered in the request to the
servlet.  In that way, you can establish the setup where a designer can just
'go at it' and still remain within the boundaries of the objects / tools
they are to use.  Futher, the programmer is only involved to make new
objects for the designer to use - something that has to be done in a JSP
environment anyway.

That would be a complete solution for the above - as long as the objects the
designer needed were in existance, they could easily put them into the
config for their servlet, and have at it creating their template.

Maybe I will write this and put in a contrib area - I don't think it belongs
in the Vel core (here we go again....), but certainly would help people in
this way.

Now, this does move away slightly from orthodox MVC, but no more than the
'Pull Model'.  Maybe a little more, as the designer can take control of the
Controller layer by specifying the template to show in the requests, but
still - it's for prototyping.

Of course, I would think that you would take the prototype and build a more
structured production app from it :)

You have the freedom to work with Velocity in any way you choose.  Bare
bones, it won't satisfy the rapid prototyping you are talking about, but
with a *tiny* bit of work, I think you can build an environment pretty
quickly that supports it.

> Yes, I know ... you may think that I have a pretty weak
> argument ... But in
> practice, using the same language/technology for the
> production application
> and the prototype does amazing things for speed of
> development ... Several
> web projects that I worked on had incredible speed increases
> because the
> designer and I were working on the same physical project and
> I could add
> functionality to the pages that he already designed and
> linked ... and vice
> versa ...

I think that what you bring up is an important issue.  I believe that
production and development process and practice certainly must be considered
in what we are doing - if not, the stuff we are building won't get used by
anyone but us, and that would be a shame.

> Like I said ... ultimately, we decided to go with Velocity
> but it certainly
> wasn't a 'no-brainer' like the article implies it should be ...

Please keep reporting back here on what you find - how it is to use.  Like I
said above, I think that real-life feedback about production use is very
important - I try to use Velocity exclusivly in my commercial consulting
work, and it has provided an enormous amount of insight for me about its use
that I turn around and put back into the project.

Having a collection of 'best practices' will only make Velocity that much
more valuable all of us.


View raw message