This looks a lot like a religious discussion and didn't your mother tell you about such having such dicsussions in public ;-\.
Edgar -----Original Message----- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 23, 2002 8:46 AM To: Struts Developers List Subject: Re: Velocity vs. JSP: objective tests? On Friday, November 22, 2002, at 04:47 PM, Craig R. McClanahan wrote: >> >>> #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. I think you are confusing webmacro syntax and velocity syntax. Velocity never supported the lack of parens in the foreach, and never supported { or } as block delimiters. > >> ... >>> * 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. > Is that true? I didn't think that general method calls were available. >> >> ... >>> >>> 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 :-). Which was another feature introduced to JSP after Velocity? It's good when the standard follows. ;-> Seriously - What Nathan was saying had nothing to do with syntax - he's suggesting that something that generates HTML output shouldn't be written in Java, but rather by a designer in the designers environment, either JSP or Velocity or whatever. So #shownavbar( true ) is a Velocimacro, a little parameterized Velocity template. $macros.showNavBar(true) might be the same thing - invoking the method showNavBar(Boolean) that uses velocity inside to render templates/macros. In that case, I think that's cool - because then the output doesn't really come from Java - it's still in velocity. geir -- Geir Magnusson Jr 203-355-2219(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] -- 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]>
