RE: Velocity vs. JSP: objective tests?
Very interesting. Since these appear to be 'competing technologies' I see you have chosen Struts over barracuda. There was a long comparison on the enhydra site which paints XMLC in a good light, but without a detailed investingation doesn't mean much. My questions are: 1) Are the technogolies incompatible (or at least the off the shelf version)? 2) How much control to you get of the client or are you force to manipulate it through a filtering layer? 3) How good are the controls it generates? Thanks in advance. Edgar -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 24, 2002 10:40 PM To: Struts Developers List Subject: RE: Velocity vs. JSP: objective tests? A DOM based rendering methodology might be more appropriate for this sort of thing. For example the home baked view technology Im using with my struts app is based around the idea of giving each page a 'layout' - this is just an xhtml file - or several actually since I tend have have some shared templating type stuff going on, and the dynamic content is inserted into the DOM by Java code. Some neat side effects of this are that one can modify the xhtml to quite an extent (or pass it on to ones website guru to make it look great) - without changing the code that renders the dynamic stuff (such as field values, menus etc..) There is a much stronger seperation between layout and content this way, which imho is a 'good thing'. Obviously the html dude and the designer have to agree on things like how to identify nodes (ie: which values to use for 'id' attributes for the most part) but it means that the two don't step on each others toes half as much as can happen with JSP. It also means one can do neat tricks like having several different layouts (skins) for ones pages and choosing from these at runtime - without having to replicate the code that renders the dynamic content in each one. Being able to randomly access any part of the page from the rendering code is also very useful. For example its a breeze to apply the decorator pattern to ones output - such as hunting for all a hef=... to modify the links in some way etc... btw This isn't a novel approach. My stuff is heavily inspired by XMLC - which is the view technology used by the Barracuda framework. See http://xmlc.enhydra.org/index.html and http://barracuda.enhydra.org/ XLMC is an interesting beastie. Instead of reading the DOMS from html files at runtime using a parser, it is used to create a class that contains the code that will build the DOM for you (not unlike the concept of JSPs being compiled to java servlets). I gather it can be setup to do this at runtime as well and you can drop in an html file and it will rebuild and reload the class. (These classes have a method that returns the DOM which can be manipulated using the org.w3c.dom classes or with a whole bunch of convienience methods XMLC provides). /btw -Original Message- From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Johnson Sent: Saturday, November 23, 2002 06:53 To: [EMAIL PROTECTED] Subject: Re: Velocity vs. JSP: objective tests? David Graham wrote: 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? What if, for example, you have an e-Commerce catalog and you want to allow ordinary users to edit the catalog item page templates through a web interface. If you Do you really want ordinary catalog users to be able to execute arbitrary code from these page templates? I don't think so. Using JSP for the user-editable page templates is really not an option in this case. Wouldn't you agree? - Dave -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
On Mon, 25 Nov 2002, Andrew Hill wrote: A DOM based rendering methodology might be more appropriate for this sort of thing. Those interested in DOM-based rendering, which you can then run through an appropriate XSLT processing pipeline, should also take a look at STXX: http://stxx.sourceforge.net/ I hope to see an even closer integration of these technologies into post-1.1 Struts releases. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
A DOM based rendering methodology might be more appropriate for this sort of thing. For example the home baked view technology Im using with my struts app is based around the idea of giving each page a 'layout' - this is just an xhtml file - or several actually since I tend have have some shared templating type stuff going on, and the dynamic content is inserted into the DOM by Java code. Some neat side effects of this are that one can modify the xhtml to quite an extent (or pass it on to ones website guru to make it look great) - without changing the code that renders the dynamic stuff (such as field values, menus etc..) There is a much stronger seperation between layout and content this way, which imho is a 'good thing'. Obviously the html dude and the designer have to agree on things like how to identify nodes (ie: which values to use for 'id' attributes for the most part) but it means that the two don't step on each others toes half as much as can happen with JSP. It also means one can do neat tricks like having several different layouts (skins) for ones pages and choosing from these at runtime - without having to replicate the code that renders the dynamic content in each one. Being able to randomly access any part of the page from the rendering code is also very useful. For example its a breeze to apply the decorator pattern to ones output - such as hunting for all a hef=... to modify the links in some way etc... btw This isn't a novel approach. My stuff is heavily inspired by XMLC - which is the view technology used by the Barracuda framework. See http://xmlc.enhydra.org/index.html and http://barracuda.enhydra.org/ XLMC is an interesting beastie. Instead of reading the DOMS from html files at runtime using a parser, it is used to create a class that contains the code that will build the DOM for you (not unlike the concept of JSPs being compiled to java servlets). I gather it can be setup to do this at runtime as well and you can drop in an html file and it will rebuild and reload the class. (These classes have a method that returns the DOM which can be manipulated using the org.w3c.dom classes or with a whole bunch of convienience methods XMLC provides). /btw -Original Message- From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Johnson Sent: Saturday, November 23, 2002 06:53 To: [EMAIL PROTECTED] Subject: Re: Velocity vs. JSP: objective tests? David Graham wrote: 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? What if, for example, you have an e-Commerce catalog and you want to allow ordinary users to edit the catalog item page templates through a web interface. If you Do you really want ordinary catalog users to be able to execute arbitrary code from these page templates? I don't think so. Using JSP for the user-editable page templates is really not an option in this case. Wouldn't you agree? - Dave -- 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]
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]
RE: Velocity vs. JSP: objective tests?
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]
Re: Velocity vs. JSP: objective tests?
I believe the Velocity site has a comparison to JSP. Of course, they like Velocity better. If it's important that new developers be productive immediately I would go with JSP because that's a java standard that they will already know. David From: micael [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Velocity vs. JSP: objective tests? Date: Fri, 22 Nov 2002 10:14:45 -0800 I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
One thing that should be considered is not a technical issue. It's clear that the number of JSP developers is much larger than Velocity developers. That doesn't mean JSP is better than Velocity, but it means that people and training will be more portable when using JSP. Assuming that same population disparity, however, you can also assume that many Velocity developers will be at least somewhat familiar with JSP, but not as much the other way around. -Original Message- From: micael [mailto:[EMAIL PROTECTED]] I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Karr, David wrote:
Date: Fri, 22 Nov 2002 11:08:49 -0800
From: Karr, David [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Velocity vs. JSP: objective tests?
One thing that should be considered is not a technical issue.
I would say it is not *just* a technical issue. There's emotion, and
personal syntax likes/dislikes, involved as well.
It's clear that the number of JSP developers is much larger than
Velocity developers. That doesn't mean JSP is better than Velocity,
but it means that people and training will be more portable when using
JSP. Assuming that same population disparity, however, you can also
assume that many Velocity developers will be at least somewhat familiar
with JSP, but not as much the other way around.
I would not necessarily make the last assumption (that Velocity developers
are at least somewhat familiar with JSP) -- especially with the recent
changes like JSTL and JSP 2.0.
The first part of the decision process is fundamentally one of preferences
for the syntax. 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.)
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
JSP 1.1 (with Scriptlets):
=
%
Customer custs = ...;
for (int i=0; i custs.length; i++) {
%
tr
td%= custs[i].getId() %/td
td%= custs[i].getName() %/td
/tr
%
}
%
JSP 1.1 (with custom tags):
==
(Note -- it is assumed here and in the following examples that the
Customer collection has been stored by some preceding business logic.)
logic:iterate id=cust name=custs
tr
tdjsp:getProperty name=cust property=id//td
tdjsp:getProperty name=cust property=name//td
/tr
/logic:iterate
JSP 1.2 + JSTL 1.0:
==
c:forEach var=cust items=${custs}
tr
tdc:out value=${cust.id}//td
tdc:out value=${cust.name}//td
/tr
/c:forEach
JSP 2.0 + JSTL 1.0:
==
c:forEach var=cust items=${custs}
tr
td${cust.id}/td
td${cust.name}/td
/tr
/c:forEach
As you can see, JSP is evolving to the point where the same kinds of
things are just as succinct as Velocity. It comes down to whether you
think using XML/HTML style elements and attributes is the greatest thing
since sliced bread or the worst possible way to describe something.
Other issues that may be important to you:
* Velocity can be used in contexts other than web presentation.
You can use it for general text transformations with dynamic
content, similar in spirit to what XSLT lets you do, for example.
Sometimes it is convenient to only have to learn one syntax
for doing multiple things.
* It's quite possible that Velocity pages will render faster than
JSP pages if the JSP page compiler isn't very good (in Tomcat,
that means before the introduction of Jasper2).
* 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.
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 :-).
At any rate, Velocity works just fine with Struts, if you choose to use
it. Ted's book (Struts in Action) has quite a bit of coverage of this.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
11/22/2002 1:14:45 PM, micael [EMAIL PROTECTED] wrote: I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? Micael The best thing is to just try the alternate approaches and decide for yourself. Personally, I would agree with the other postings: the pro of JSP is that a lot of people already use it. =:0) Otherwise, in a MVC/Model 2 application, the two are technically equivalent. It's really not about which works best, it's about which works best for you. There's an simple register application at SourceForge that shows a couple of JSP and Velocity pages side-by-side. http://prdownloads.sourceforge.net/struts/logon-velocity.war? download Here's more sophisticated application that I'm working on now: http://prdownloads.sourceforge.net/wqdata/cpu_20021121.war? download No business logic yet, but you can see how things work. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
David said: I believe the Velocity site has a comparison to JSP. Of course, they like Velocity better. If it's important that new developers be productive immediately I would go with JSP because that's a java standard that they will already know. also, if you haven't already, be sure you look into the Velocity Tools subproject. a fair bit of work has already been done there to integrate Struts and Velocity. personally, i use the two together and am really enjoying the process. i'm of the lucky few :) that has had almost no experience with JSP, so i'm no doubt a little biased, but i don't think you need to worry about time spent learning Velocity. it's really quite small and simple; the basics can be picked up quickly. if you want to do JSP well, you can easily spend more time learning taglibs (unless you already know them of course). one thing that may ease your concern is that with the Velocity Tools project, it is quite easy to use both Velocity and JSP side by side. there are examples included there for that. also, the Veltag allows you to use Velocity right inside JSP (link below). the one drawback you should be aware of for Struts+Velocity is that not as many people do it yet, and there's not exactly prodigous amounts of documentation or examples floating around yet. the Velocity Tools stuff is a good start though, and if you look into it, be aware that much of the documentation for tool management and such is mostly in the javadocs right now. here's some links that may be of interest to you: Gabe Sidler's docs on Velocity+Struts: http://www.teamup.com/jakarta-velocity-tools/struts/docs/index.html Velocity Tools home: http://jakarta.apache.org/velocity/toolsubproject.html Veltag: http://jakarta.apache.org/velocity/veltag.html Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
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]
Re: Velocity vs. JSP: objective tests?
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
[EMAIL PROTECTED]
Craig
--
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]
RE: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Matt Raible wrote: Date: Fri, 22 Nov 2002 14:38:02 -0700 From: Matt Raible [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Velocity vs. JSP: objective tests? 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! It would also be an interesting experiment to see how people would approach this with JSP (and probably using Tiles for the standard layout stuff). Thanks, Matt Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
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.
David
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
Re: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, David Graham wrote: Date: Fri, 22 Nov 2002 14:55:55 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Velocity vs. JSP: objective tests? 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. It is, in fact, not a big concern of mine. It's one of the arguments that Velocity advocates originally made, and is also one of things people like Jason Hunter like about Tea (which is now on SF at http://teatrove.sourceforge.net). See Jason's thoughts about Tea on his website http://www.servlets.com and the 2nd edition of Java Servlet Programming. The concern, as I understand it, is not so much about deliberately malicious page developers, but those that make errors that are not caught prior to production deployment, which result in things like stack traces shown to the end user. David Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Matt said: 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! Velocimacros are what you want. you can create a specify a library template of velocimacros in your velocity.properties that would be available to all your templates. see http://jakarta.apache.org/velocity/user-guide.html#Velocimacros this provides some nice encapsulation to avoid both hard-coding html or xml or whatever and yet not have to copy-paste or retype the same stuff every time. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Craig said: ... 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. yeah, it may have been right (or closer) once, but not since at least two years ago (when i started using velocity). ... * 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. yep, that's what i said. we agree then! :) ... 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 :-). looks can be deceiving! with a proper velocimacro, the HTML isn't hard-coded into java classes. that may not be important to some folks, but it is to me. i think it goes a long way toward *encouraging* good MVC separation. it's not just a matter of syntax, but of design philosophy as well. ... 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. yeah, i haven't gotten to see it, but i heard he talked about the Velocity+Struts stuff in it. i'm hoping it gets more people looking into and/or using that code. i think there's some good potential there, but progress has kinda plateaued lately. it could use some fresh users/contributers to prod things along. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
David Graham wrote: 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? What if, for example, you have an e-Commerce catalog and you want to allow ordinary users to edit the catalog item page templates through a web interface. If you Do you really want ordinary catalog users to be able to execute arbitrary code from these page templates? I don't think so. Using JSP for the user-editable page templates is really not an option in this case. Wouldn't you agree? - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
JSP wouldn't be an option anyways because ordinary users wouldn't understand it. The vast majority of situations are not like the one you describe. David From: Dave Johnson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Velocity vs. JSP: objective tests? Date: Fri, 22 Nov 2002 17:53:28 -0500 David Graham wrote: 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? What if, for example, you have an e-Commerce catalog and you want to allow ordinary users to edit the catalog item page templates through a web interface. If you Do you really want ordinary catalog users to be able to execute arbitrary code from these page templates? I don't think so. Using JSP for the user-editable page templates is really not an option in this case. Wouldn't you agree? - Dave -- 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]
Re: Velocity vs. JSP: objective tests?
David Graham wrote: JSP wouldn't be an option anyways because ordinary users wouldn't understand it. The vast majority of situations are not like the one you describe. You are correct. More imporantly, if you are choosing between JSP and Velocity as your Struts View technology then the scenario that I cited is irrelevant. - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Nathan Bubna wrote: [big snip] #showNavBar( true) Fine ... still looks like a scriptlet to me :-). looks can be deceiving! with a proper velocimacro, the HTML isn't hard-coded into java classes. that may not be important to some folks, but it is to me. i think it goes a long way toward *encouraging* good MVC separation. it's not just a matter of syntax, but of design philosophy as well. A similar feature is part of JSP 2.0, by the way. A page author can point at a chunk of JSP code (rather than Java) and create a reusable widget, optionally with parameters, which the JSP compiler essentially turns into a custom tag automatically. The page author using the widget invokes it just like any other custom tag. Among other things, this supports the kind of separation you suggest. Nathan Bubna [EMAIL PROTECTED] Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Roller-development] RE: Velocity vs. JSP: objective tests?
No offence taken, but I do have some comments, which are 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. :) In the case of the NavBar, there was an existing JSP NavBar tag and I wanted to use that NavBar from Velocity. In general, I think you (whoever you are) are correct: the Velocity template (or a Velocity macro) should be responsible for creating the HTML based on the model objects that have been placed into the context. If we want to follow your advice in Roller development, we should stop adding HTML generation methods to our $macros object. Instead we should put the right objects into the Velocity context and let Velocity do the rendering, possibly by calling upon Velocity macros. It would also be an interesting experiment to see how people would approach this with JSP (and probably using Tiles for the standard layout stuff). I' not sure how you would do user-editable weblog page templates using JSP, that is why I did it using Velocity. I don't think you want users editing JSP templates, in fact you don't even want them to be able to access the request and response objects - it's just too dangerous. - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Roller-development] RE: Velocity vs. JSP: objective tests?
Dave said: No offence taken, but I do have some comments, which are 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. :) In the case of the NavBar, there was an existing JSP NavBar tag and I wanted to use that NavBar from Velocity. In general, I think you (whoever you are) are correct: the Velocity template (or a Velocity macro) should be responsible for creating the HTML based on the model objects that have been placed into the context. [snip] yeah, i had a feeling it was something like that. i can see that that is useful for initial development, but unless you have some real need to keep that HTML output always in sync with the NavBar tag, i think it would be best to move away from that as you continue to develop the product. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
