You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Paul Gillen <pa...@gmail.com> on 2006/01/11 21:12:46 UTC
Rationale for Velocity?
My new employer uses Velocity for page display technology. In answer
to the question "why?" I get "its our standard". True, but
intellectually unsatisfying. Everything else is written in Java/JSP
which is in itself a powerful and functionally rich page display
technology. Velocity on the other hand appears to be functionally
deficient, i.e. the absence of a "for" loop. Even were this not true,
why change technologies when we get down to the view layer? Why take
things out of a "session" construct only to put them in a "context"
construct for the convenience of Velocity when were we sticking with
JSP this step would be unnecessary? Not trying to piss on anybody's
foot. Looks like lots of folks use it. Looks like I'm stuck with it.
But I'm still looking for an answer to the question, "Why?"
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Rationale for Velocity?
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Paul,
For zero or one based indices, are you familiar with $velocityCount? It's
the current index of the #foreach. Not quite the same, but combine it with
a #set and you are equivalent with just one extra line.
Also, (re: comment switching view techologies), you might want to see this
article for background on different approaches with webapps. Personally, I
generally follow a MVC approach with a framework like Spring MVC, Struts,
Maverick, (or my own servlet). I don't think of Velocity as "switching
technologies", I think of it as one of a couple of choices.
http://jakarta.apache.org/velocity/webapps.html
Good luck with your project. Let us know if you need other advice or
assistance...
Best,
WILL
----- Original Message -----
From: "Paul Gillen" <pa...@gmail.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Wednesday, January 11, 2006 12:47 PM
Subject: Re: Rationale for Velocity?
Thanks for the prompt response Will. My suspicion was that the need for
Velocity was largely historical; you have, to some extent, confirmed that
with the "JSP 2.0 is much improved" comment.
In re the "functionally deficient, no for; try #foreach" discussion, we do
use #foreach. I'm looking at converting a JSP view to Velocity. I have a
LinkedList of product info I want to page through. With JSP its:
for (idx=firstOnPage; idx<=lastOnPage; idx++)
With Velocity I either have to create a new LinkedList containing only the
products I wish to display at this time with a #foreach or I #foreach/spin
through the entire LinkedList with a counter, stopping to process the first
though last, and then continuing to spin.
Your other comments are well taken but largely inapplicable here; after all,
I'm not "less technical", I'm a guru B<) The 'email template' comment is
interesting though; more research required on my part.
Thanks again
=Paul=
On 1/11/06, Will Glass-Husain <wg...@forio.com> wrote:
>
> Hi Paul,
>
> I develop apps that use either Velocity or JSP / JSTL on a regular basis.
> Both are good tools.
>
> To keep things short, user feedback on Velocity is
> * Velocity has a simpler syntax and is often easier to use for less
> technical users.
> * Highly customizable (I run a site that has a domain-specific page markup
> language used by hundreds of users)
> * Can be used for web pages, email templates, code generation (not just
> web
> pages like JSP).
>
> I used to complain about JSP all the time (unreadable spaghetti scripts,
> long-winded syntax, complex tag API) but JSP 2.0 is much improved. I like
> the large user base and the IDE support. The latter exists for Velocity
> but
> is not as featured.
>
> There's more on this at this link.
> http://jakarta.apache.org/velocity/overview.html
>
> Re: the "functionally deficient" comment. Basically, Velocity focuses on
> "Presentation" instead of "Scripting". The idea is that you include
> markup
> in pages rather than a spaghetti code of scripts. (which can quickly
> become
> unmaintainable in a large site). This is a different philosophy than PHP
> or
> old-style JSP.
>
> And there is indeed a #foreach in Velocity. If you'd like ideas about
> using
> that, I suggest you open a new thread.
>
> Cheers,
>
> WILL
>
>
>
>
> ----- Original Message -----
> From: "Paul Gillen" <pa...@gmail.com>
> To: <ve...@jakarta.apache.org>
> Sent: Wednesday, January 11, 2006 12:12 PM
> Subject: Rationale for Velocity?
>
>
> My new employer uses Velocity for page display technology. In answer
> to the question "why?" I get "its our standard". True, but
> intellectually unsatisfying. Everything else is written in Java/JSP
> which is in itself a powerful and functionally rich page display
> technology. Velocity on the other hand appears to be functionally
> deficient, i.e. the absence of a "for" loop. Even were this not true,
> why change technologies when we get down to the view layer? Why take
> things out of a "session" construct only to put them in a "context"
> construct for the convenience of Velocity when were we sticking with
> JSP this step would be unnecessary? Not trying to piss on anybody's
> foot. Looks like lots of folks use it. Looks like I'm stuck with it.
> But I'm still looking for an answer to the question, "Why?"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
---------------------
Paul D. Gillen
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Rationale for Velocity?
Posted by Barbara Baughman <ba...@utdallas.edu>.
I just wanted to add that, as a programmer, I find it easier to
maintain Velocity templates than JSP pages. Like orders of magnitude
easier (of course, that was in the bad old days of JSP). I started
programming web applications in JSP and switched happily to Velocity.
Many times, I've made radical changes to the underlying application
program without ever needing to touch the Velocity templates.
The #foreach directive serves most needs for a loop, and the Velocity
Tools project has some other useful tools for handling lists. Mostly,
I just try to pass objects to the Velocity context that have precisely
what I would want to list. Another alternative is to provide a public
method to the context that will screen a larger list to a smaller list
for the #foreach directive.
Barbara Baughman
X2157
On Wed, 11 Jan 2006, Paul Gillen wrote:
> Thanks for the prompt response Will. My suspicion was that the need for
> Velocity was largely historical; you have, to some extent, confirmed that
> with the "JSP 2.0 is much improved" comment.
>
> In re the "functionally deficient, no for; try #foreach" discussion, we do
> use #foreach. I'm looking at converting a JSP view to Velocity. I have a
> LinkedList of product info I want to page through. With JSP its:
> for (idx=firstOnPage; idx<=lastOnPage; idx++)
> With Velocity I either have to create a new LinkedList containing only the
> products I wish to display at this time with a #foreach or I #foreach/spin
> through the entire LinkedList with a counter, stopping to process the first
> though last, and then continuing to spin.
>
> Your other comments are well taken but largely inapplicable here; after all,
> I'm not "less technical", I'm a guru B<) The 'email template' comment is
> interesting though; more research required on my part.
>
> Thanks again
> =Paul=
>
> On 1/11/06, Will Glass-Husain <wg...@forio.com> wrote:
> >
> > Hi Paul,
> >
> > I develop apps that use either Velocity or JSP / JSTL on a regular basis.
> > Both are good tools.
> >
> > To keep things short, user feedback on Velocity is
> > * Velocity has a simpler syntax and is often easier to use for less
> > technical users.
> > * Highly customizable (I run a site that has a domain-specific page markup
> > language used by hundreds of users)
> > * Can be used for web pages, email templates, code generation (not just
> > web
> > pages like JSP).
> >
> > I used to complain about JSP all the time (unreadable spaghetti scripts,
> > long-winded syntax, complex tag API) but JSP 2.0 is much improved. I like
> > the large user base and the IDE support. The latter exists for Velocity
> > but
> > is not as featured.
> >
> > There's more on this at this link.
> > http://jakarta.apache.org/velocity/overview.html
> >
> > Re: the "functionally deficient" comment. Basically, Velocity focuses on
> > "Presentation" instead of "Scripting". The idea is that you include
> > markup
> > in pages rather than a spaghetti code of scripts. (which can quickly
> > become
> > unmaintainable in a large site). This is a different philosophy than PHP
> > or
> > old-style JSP.
> >
> > And there is indeed a #foreach in Velocity. If you'd like ideas about
> > using
> > that, I suggest you open a new thread.
> >
> > Cheers,
> >
> > WILL
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Paul Gillen" <pa...@gmail.com>
> > To: <ve...@jakarta.apache.org>
> > Sent: Wednesday, January 11, 2006 12:12 PM
> > Subject: Rationale for Velocity?
> >
> >
> > My new employer uses Velocity for page display technology. In answer
> > to the question "why?" I get "its our standard". True, but
> > intellectually unsatisfying. Everything else is written in Java/JSP
> > which is in itself a powerful and functionally rich page display
> > technology. Velocity on the other hand appears to be functionally
> > deficient, i.e. the absence of a "for" loop. Even were this not true,
> > why change technologies when we get down to the view layer? Why take
> > things out of a "session" construct only to put them in a "context"
> > construct for the convenience of Velocity when were we sticking with
> > JSP this step would be unnecessary? Not trying to piss on anybody's
> > foot. Looks like lots of folks use it. Looks like I'm stuck with it.
> > But I'm still looking for an answer to the question, "Why?"
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
>
>
> --
> ---------------------
> Paul D. Gillen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Rationale for Velocity?
Posted by Paul Gillen <pa...@gmail.com>.
Thanks for the prompt response Will. My suspicion was that the need for
Velocity was largely historical; you have, to some extent, confirmed that
with the "JSP 2.0 is much improved" comment.
In re the "functionally deficient, no for; try #foreach" discussion, we do
use #foreach. I'm looking at converting a JSP view to Velocity. I have a
LinkedList of product info I want to page through. With JSP its:
for (idx=firstOnPage; idx<=lastOnPage; idx++)
With Velocity I either have to create a new LinkedList containing only the
products I wish to display at this time with a #foreach or I #foreach/spin
through the entire LinkedList with a counter, stopping to process the first
though last, and then continuing to spin.
Your other comments are well taken but largely inapplicable here; after all,
I'm not "less technical", I'm a guru B<) The 'email template' comment is
interesting though; more research required on my part.
Thanks again
=Paul=
On 1/11/06, Will Glass-Husain <wg...@forio.com> wrote:
>
> Hi Paul,
>
> I develop apps that use either Velocity or JSP / JSTL on a regular basis.
> Both are good tools.
>
> To keep things short, user feedback on Velocity is
> * Velocity has a simpler syntax and is often easier to use for less
> technical users.
> * Highly customizable (I run a site that has a domain-specific page markup
> language used by hundreds of users)
> * Can be used for web pages, email templates, code generation (not just
> web
> pages like JSP).
>
> I used to complain about JSP all the time (unreadable spaghetti scripts,
> long-winded syntax, complex tag API) but JSP 2.0 is much improved. I like
> the large user base and the IDE support. The latter exists for Velocity
> but
> is not as featured.
>
> There's more on this at this link.
> http://jakarta.apache.org/velocity/overview.html
>
> Re: the "functionally deficient" comment. Basically, Velocity focuses on
> "Presentation" instead of "Scripting". The idea is that you include
> markup
> in pages rather than a spaghetti code of scripts. (which can quickly
> become
> unmaintainable in a large site). This is a different philosophy than PHP
> or
> old-style JSP.
>
> And there is indeed a #foreach in Velocity. If you'd like ideas about
> using
> that, I suggest you open a new thread.
>
> Cheers,
>
> WILL
>
>
>
>
> ----- Original Message -----
> From: "Paul Gillen" <pa...@gmail.com>
> To: <ve...@jakarta.apache.org>
> Sent: Wednesday, January 11, 2006 12:12 PM
> Subject: Rationale for Velocity?
>
>
> My new employer uses Velocity for page display technology. In answer
> to the question "why?" I get "its our standard". True, but
> intellectually unsatisfying. Everything else is written in Java/JSP
> which is in itself a powerful and functionally rich page display
> technology. Velocity on the other hand appears to be functionally
> deficient, i.e. the absence of a "for" loop. Even were this not true,
> why change technologies when we get down to the view layer? Why take
> things out of a "session" construct only to put them in a "context"
> construct for the convenience of Velocity when were we sticking with
> JSP this step would be unnecessary? Not trying to piss on anybody's
> foot. Looks like lots of folks use it. Looks like I'm stuck with it.
> But I'm still looking for an answer to the question, "Why?"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
---------------------
Paul D. Gillen
Re: Rationale for Velocity?
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Paul,
I develop apps that use either Velocity or JSP / JSTL on a regular basis.
Both are good tools.
To keep things short, user feedback on Velocity is
* Velocity has a simpler syntax and is often easier to use for less
technical users.
* Highly customizable (I run a site that has a domain-specific page markup
language used by hundreds of users)
* Can be used for web pages, email templates, code generation (not just web
pages like JSP).
I used to complain about JSP all the time (unreadable spaghetti scripts,
long-winded syntax, complex tag API) but JSP 2.0 is much improved. I like
the large user base and the IDE support. The latter exists for Velocity but
is not as featured.
There's more on this at this link.
http://jakarta.apache.org/velocity/overview.html
Re: the "functionally deficient" comment. Basically, Velocity focuses on
"Presentation" instead of "Scripting". The idea is that you include markup
in pages rather than a spaghetti code of scripts. (which can quickly become
unmaintainable in a large site). This is a different philosophy than PHP or
old-style JSP.
And there is indeed a #foreach in Velocity. If you'd like ideas about using
that, I suggest you open a new thread.
Cheers,
WILL
----- Original Message -----
From: "Paul Gillen" <pa...@gmail.com>
To: <ve...@jakarta.apache.org>
Sent: Wednesday, January 11, 2006 12:12 PM
Subject: Rationale for Velocity?
My new employer uses Velocity for page display technology. In answer
to the question "why?" I get "its our standard". True, but
intellectually unsatisfying. Everything else is written in Java/JSP
which is in itself a powerful and functionally rich page display
technology. Velocity on the other hand appears to be functionally
deficient, i.e. the absence of a "for" loop. Even were this not true,
why change technologies when we get down to the view layer? Why take
things out of a "session" construct only to put them in a "context"
construct for the convenience of Velocity when were we sticking with
JSP this step would be unnecessary? Not trying to piss on anybody's
foot. Looks like lots of folks use it. Looks like I'm stuck with it.
But I'm still looking for an answer to the question, "Why?"
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Rationale for Velocity?
Posted by mailmur <ma...@yahoo.com>.
Where I use Velocity tools is not rendering html
pages. I solely use it as "sql rendering" utility. I
have template files where I have sql queries. I use
velocity to create the final sql formula string and
run it against the database.
And applications are nothing to do with Tomcat, JSP,
servlet engines. Its plain old standalone desktop
application.
I have subclasses VelocityContext and added helper
methods.
[ templateFile userUpdate.vm ]
Update tTable Set
id=$userId,
updated=$updated,
name=$name
Where id=$userId
ctx = new SQLQueryContext("sql/userUpdate.vm");
ctx.setInt("userId", userBean.getId());
ctx.setDate("updated", userBean.lastUpdated());
ctx.setName("name", userBean.getName());
...
String sql = ctx.createQuery();
Helper class handles all sql escaping (convert single
' to double ''), gives me named parameters, etc...
If I want to do something fancy, I can easily create
conditional sql template files.
#if ($id > 100)
Update tTable Set
id=$userId,
updated=$updated,
name=$name
Where id=$userId
#else
Update tTableForLessThan100Ids Set
id=$userId,
updated=$updated,
name=$name
Where id=$userId
#end
--- Nathan Bubna <nb...@gmail.com> wrote:
> While this essay is a bit old, i believe a lot of it
> is still relevant.
>
http://wiki.apache.org/jakarta-velocity/YouMakeTheDecision
>
> and while JSP 2.0 (with JSTL) is certainly "much
> improved", the simple
> reality is that its syntax will always be uglier and
> more unweildy and
> remains restricted to web environments. i've lately
> had to work on my
> first big JSP/JSTL project and am continually
> appalled and some of the
> syntactical nonsense i have to deal with. the IDE
> support helps
> though, as do the Velocity-ish features added with
> 2.0 and JSTL. i'm
> quite glad to never have been forced to use JSP 1.x
> for anything
> significant before these came out.
>
> oh, and your "why take things out of a 'session'..."
> complaint is a
> shortcoming of whatever servlet/controller you are
> using, in my
> opinion. if you use the VelocityViewServlet from
> the VelocityTools
> project, you can automaticaly access session
> attributes (and more)
> directly in your templates without any need to
> manually add them to
> your context.
>
> On 1/11/06, Paul Gillen <pa...@gmail.com>
> wrote:
> > My new employer uses Velocity for page display
> technology. In answer
> > to the question "why?" I get "its our standard".
> True, but
> > intellectually unsatisfying. Everything else is
> written in Java/JSP
> > which is in itself a powerful and functionally
> rich page display
> > technology. Velocity on the other hand appears to
> be functionally
> > deficient, i.e. the absence of a "for" loop. Even
> were this not true,
> > why change technologies when we get down to the
> view layer? Why take
> > things out of a "session" construct only to put
> them in a "context"
> > construct for the convenience of Velocity when
> were we sticking with
> > JSP this step would be unnecessary? Not trying to
> piss on anybody's
> > foot. Looks like lots of folks use it. Looks like
> I'm stuck with it.
> > But I'm still looking for an answer to the
> question, "Why?"
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Rationale for Velocity?
Posted by Nathan Bubna <nb...@gmail.com>.
While this essay is a bit old, i believe a lot of it is still relevant.
http://wiki.apache.org/jakarta-velocity/YouMakeTheDecision
and while JSP 2.0 (with JSTL) is certainly "much improved", the simple
reality is that its syntax will always be uglier and more unweildy and
remains restricted to web environments. i've lately had to work on my
first big JSP/JSTL project and am continually appalled and some of the
syntactical nonsense i have to deal with. the IDE support helps
though, as do the Velocity-ish features added with 2.0 and JSTL. i'm
quite glad to never have been forced to use JSP 1.x for anything
significant before these came out.
oh, and your "why take things out of a 'session'..." complaint is a
shortcoming of whatever servlet/controller you are using, in my
opinion. if you use the VelocityViewServlet from the VelocityTools
project, you can automaticaly access session attributes (and more)
directly in your templates without any need to manually add them to
your context.
On 1/11/06, Paul Gillen <pa...@gmail.com> wrote:
> My new employer uses Velocity for page display technology. In answer
> to the question "why?" I get "its our standard". True, but
> intellectually unsatisfying. Everything else is written in Java/JSP
> which is in itself a powerful and functionally rich page display
> technology. Velocity on the other hand appears to be functionally
> deficient, i.e. the absence of a "for" loop. Even were this not true,
> why change technologies when we get down to the view layer? Why take
> things out of a "session" construct only to put them in a "context"
> construct for the convenience of Velocity when were we sticking with
> JSP this step would be unnecessary? Not trying to piss on anybody's
> foot. Looks like lots of folks use it. Looks like I'm stuck with it.
> But I'm still looking for an answer to the question, "Why?"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Rationale for Velocity?
Posted by Peter Harrison <pe...@nbn.co.nz>.
On Wed, 2006-01-11 at 15:12 -0500, Paul Gillen wrote:
> My new employer uses Velocity for page display technology. In answer
> to the question "why?" I get "its our standard".
There are some very powerfull reasons I use Velocity in my company.
1. Separation of logic from html. This is NOT separation of Model from
UI. It means a separation of the HTML so that HTML coders do not need to
worry so much about proramming. While Taglibs have moved JSP to have
less imbedded code there is still the ability - the temptation - to put
a quick fix into JSP. Even when HTML and coding is done by the same
person having a clear demarkation between code and html means that there
is no confusion about where something is done.
2. No compile stage. I hate having to debug JSP on different application
servers. Although I primarily use Tomcat we had previous issues with
running a app that worked fine under Tomcat not work under Resin because
Resin created slightly different code from the JSP's.
3. Flexibility. JSP is tied to HTTP. With Velocity we can write the same
report, and have it output in HTML, PDF or OpenOffice. We have a
different XML transform for each, and also post processing for PDF and
OpenOffice formats, but essentially Velocity is used to create the
initial raw view. With JSP the output is HTTP/HTML, and you have no
opportunity for XSLT server side transforms or post transform
processing.
4. Reloading. You can replace vm files without restarting the app
server. Yeah - I know - you are *meant* to be able to do the same with
JSP. The reality for me is that reloading JSP is unreliable, especially
when it comes to picking up the database pool and other static
resources.
Finally I would like to say that Velocity is ideologically more simple,
without boring translation into code. It is not perfect however - and
there are a long standing gotchas - the set(null) issue being the worst
of them.
> Velocity on the other hand appears to be functionally
> deficient, i.e. the absence of a "for" loop.
There is a for loop. ????
> Even were this not true,
> why change technologies when we get down to the view layer? Why take
> things out of a "session" construct only to put them in a "context"
> construct for the convenience of Velocity when were we sticking with
> JSP this step would be unnecessary?
There are servlets which take care of all of this for you.
> Not trying to piss on anybody's
> foot. Looks like lots of folks use it. Looks like I'm stuck with it.
> But I'm still looking for an answer to the question, "Why?"
Because we don't want html jockies messing our code up ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org