On May 26, 2010, at 10:22 AM, Nikolaos Giannopoulos wrote:
> Morten et al.,
>
> OK... I'll bite... . I really didn't want this to devolve into "my choice"
> of templating engine is better, and there are many comparisons out there, but
> we are developing a large project and if I'm going to find the need to switch
> down the road better NOW than later.
>
I picked up Velocity, and mind I've been using it off and on since inception
which was, like, 2001. The group I was working with had their own scheme all
worked out and I beat them over the head to convince them that Velocity was a
better choice than rolling our own.
That said, I ONLY use it for templating. I don't use it for "web pages". There
I use JSP. Why? Not for any specific technical reasons. Mostly because I'm lazy.
JSPs have all sorts of features. Notably, they already work, nothing to
download, nothing to configure. Stripes works with JSPs out of the box. JSTL
and EL and Tag Files ROCK. Lazy wins, I get all of those JSP benefits "for
free". That's just how I roll.
For templating though, Velocity.
Why?
It's more robust that regex solutions, and it's faster. A regex solution
basically copies your message N times. That's a waste.
It's TRIVIAL to integrate. You have the velocity.jar, and very few, if any,
dependencies. Hard to imagine anything out of Apache not using commons logging
for example, but that's probably it.
It was easy to modify. I had to hack our version (long long ago) to support a
"generic" variable type. We had a specific need for a rule language, and it's
data type was a generic variable that could be number, string, or date. And I
wanted better flexibility in how it worked. Notably I wanted date math (date +
1 == tomorrow) expressions. Mind, I hacked the grammar and parser here. I
offered the changes to the project but they didn't want them, so we just forked
it. No bid deal.
That was straightforward for me to implement.
Did I look at other options? No, not really. Velocity was simple and robust
enough to do what we needed. We had some other clients using it that pushed it
far beyond what I did, which is the advantage of having something that we
didn't have to develop. They wrote some very complicated reports in velocity.
Here's the integration example:
public class VelocityRenderer {
String source;
Map map;
/** Creates a new instance of VelocityRenderer */
public VelocityRenderer() {
}
public VelocityRenderer(String source, Map map) {
this.source = source;
this.map = map;
}
public String render() {
StringWriter sw = new StringWriter();
try {
Velocity.init();
VelocityContext context = new VelocityContext();
for(Object key : map.keySet()) {
context.put((String)key, map.get(key));
}
Velocity.evaluate(context, sw, "Page Creation", source);
} catch (MethodInvocationException ex) {
ex.printStackTrace();
} catch (ResourceNotFoundException ex) {
ex.printStackTrace();
} catch (ParseErrorException ex) {
ex.printStackTrace();
} catch (IOException ex) {
ex.printStackTrace();
} catch (Exception ex) {
ex.printStackTrace();
}
return sw.toString();
}
}
It takes a source string, which is a Velocity script, and a map of variables,
and renders it.
It's 1/2 exception handling. It can be much more sophisticated than this
(resource lookup, cached templates, etc.) I didn't need any of that.
The Velocity guys advocate using Velocity over JSP, and have a bunch of web
stuff for that that I've never used (like a VelocityServlet, and toolboxes to
add request handling in the scripts, etc.)
We've used it for emails and reports. We even used it for declarative
validation code before we picked up Javascript. If the Velocity script rendered
in to "true" it passed, otherwise it didn't.
So, it's a great hammer. Writing your own is simply insane.
Regards,
Will Hartung
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
