velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Williams <>
Subject Re: [ANN] Viento - WHY?
Date Thu, 06 Oct 2005 19:18:43 GMT
On 10/6/05, Daniel Dekany <> wrote:
> Thursday, October 6, 2005, 1:31:47 PM, Steve O'Hara wrote:
> >
> > Am I missing something here......??
> >
> > There seems to be a whole load of template laguages springing up all
> > over the place that look very similar to Velocity, each claiming it
> > solves a view problem that Velocity doesn't.

Thanks for the discussion. What doesn't kill you makes you stronger ;)

For one thing, in-line maps don't work in Velocity. I looked into
fixing that, and even offered $100US to this list (which I hereby
revoke), but I couldn't figure out how to fix it quickly enough that

Aside from that, I can only say again, Velocity is great, but didn't
fit our needs. If you like it, and have no need to change, don't. I
for one am often overwhelmed by the number of options the Java
community has. Rails has addressed this by giving the gift of not
/having/ to choose. It is cheaper not to. We want to capture that in

For those who care, what we really needed was a way to extend the
language at runtime, differently for each Sails application, that is
easy and consistent. For example, the if in Viento is just a Class,
exposed as 'if'. You can override that, for any particular template,
easily. Or, you can take any other object and 'mixin' to your
template's binding. Velocity can be extended by 1) creating a custom
directive (that seemed really hard to do, but I'm slow), 2) writing
custom macros, which aren't as easily tested 3) pojo tools. I know
about the Uberspect - it seemed that we would have needed to rewrite
it to acheive a few of our goals.

While Viento is /reminiscent/ of Velocity, it's core design is
/completely different/. This design enables
 * A succinct syntax (which is what we loved about Velocity)
 * Extreme consistency
 * Core language constructs are implemented with no knowledge of
parser/ast, and can be replaced - you can write more (for instance, at
this time there is no #set equivalent, but it would only be a few
lines of code, with no parser/ast changes)
 * Mixed in instances have no knowledge of the ast. Did I say that already?

Anywho, there is probably more I can say, but I'll stop doing so on
this list. There might be more at - we
can work there.

Thank you so much for your time. Hope to see you Sailing someday....

 adam williams

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message