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>
<td><jsp:getProperty name="cust" property="id"/></td>
<td><jsp:getProperty name="cust" property="name"/></td>
</tr>
</logic:iterate>
JSP 1.2 + JSTL 1.0:
==================
<c:forEach var="cust" items="${custs}">
<tr>
<td><c:out value="${cust.id}"/></td>
<td><c: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]>
