See comments below... > 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) > > 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. :)
As I am a committer on the Roller project - I'm curious to know what a better way of implementing this would be. We do want Roller to be a best-practices examples - so any advice is appreciated! Thanks, Matt > -----Original Message----- > From: Nathan Bubna [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 2:12 PM > To: Struts Developers List > 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. :-) > > ... > > * 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. > > ... > > > > 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) > > 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. :) > > Nathan Bubna > [EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: > <mailto:struts-dev-> [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]>
