I've always found it amusing that people are worried about page authors totally screwing up the application by executing arbitrary code. Who are these rogue page authors you're hiring that will destroy your app?

"We can't pass anything but a value bean with read only properties to this idiot page designers or they'll screw us!".

I'm not implying that this is your view Craig, I have heard architects use this argument before though.


From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: Velocity vs. JSP: objective tests?
Date: Fri, 22 Nov 2002 13:47:48 -0800 (PST)

On Fri, 22 Nov 2002, Nathan Bubna wrote:

> Date: Fri, 22 Nov 2002 13:12:19 -0800
> From: Nathan Bubna <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Velocity vs. JSP: objective tests?
> Craig said:
> ...
> > For example, here's a simple little loop example in
> > Velocity syntax and a couple approaches in JSP:
> >
> > Velocity:
> > ========
> >
> > (Note -- it's assumed that the Customer collection has been stored in the
> > VelocityContext by some preceding business logic.)
> actually, if you are using the Velocity/Struts support in the Velocity Tools
> project, the recommended pattern is to define a set of "tools" in an xml
> config. these will then be automatically placed in the template's Context
> and available for you to "pull" the needed data. there are other ways of
> getting objects into the template still, but i don't have time to detail
> them here. see the docs concerning the VelocityViewServlet for that. oh,
> and Jon Stevens does a good job of explaining the Pull MVC Model here:
> http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
> > #foreach $result in $results {
> > <tr>
> > <td>$result.ID</td>
> > <td>$result.Name</td>
> > </tr>
> > }
> actually, this is syntax is almost completely wrong. :)
> a more fitting example would be:
> #foreach( $result in $sometool.results )
> <tr>
> <td>$result.ID</td>
> <td>$result.Name</td>
> </tr>
> #end
> velocity and it's supporting tools are evolving too. :-)

Sorry ... I was following an example from a published article (don't
remember where) so I presume that it (at least) *used* to be correct :-0.

> ...
> > * Velocity advocates used to argue that using Velocity was safer
> > because it restricted what a page designer could do to calling
> > getter methods. This was never a completely true argument
> > (how do *you* know that the getter method of the beans you are
> > calling doesn't mutate something?), but it's been pretty much
> > eliminated by the fact that you can call arbitrary methods
> > in Velocity.
> yes, it is possible to design badly even in Velocity, but perhaps we could
> agree it's at least harder in Velocity to do so.

Harder != Impossible.

This used to be the most compelling pro-Velocity argument, IMHO,
especially for people managing large content-rich web sites where you
really don't want a page author to be able to totally screw things up by
executing arbitarry code. General method calls are very convenient (and
they're in JSP 2.0's version of the expression language as well :-), but
there is no longer a difference in this regard.

> ...
> >
> > There was an interesting article on onjava.com about a project to
> > implement a simple blogger app that used both Struts and Velocity:
> >
> > http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
> >
> > I was particularly struck by the following snippet of Velocity code:
> >
> > $macros.showNavBar(true)
> >
> > which builds part of the UI by rendering the navigation bar. I don't know
> > about you, but that looks an awful lot like a scriptlet equivalent:
> >
> > <% macros.showNavBar(true); %>
> >
> > to me :-).
> yeah, no offense intended to David Johnson, but that's a really poor way to
> use Velocity. it looks as though that method is intended to spit out some
> HTML hardcoded into whatever $macros is or some such thing. the HTML
> shouldn't come from the java, it should be in the template to begin with, or
> at least defined the global Velocimacro library. that way the code could
> just be:
> #showNavBar( true)

Fine ... still looks like a scriptlet to me :-).

It's very reasonable to have a preference for one kind of syntax over the
other. And it's probably fine to make a choice between the two solely, or
primarily, on this basis. I just get amused by people who contend that
the relatively minor syntax differences are fundamental technical
discriminators between two architectures.

> anyway, i hope i'm not coming off too argumentative, it's just that these
> are poor examples of using velocity. i wouldn't want people to get the
> wrong idea. :)

Nah, we're just having a reasonable discussion, unlike some of the more
adamant Velocity advocates :-).

Actually, Ted's Struts book (Struts In Action) devotes an entire chapter
to using Velocity and Struts together, including how VelocityViewServlet
helps you out. It would make a pretty good starting point for people
interested in learning how to combine them.

> Nathan Bubna


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

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

Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

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

Reply via email to