velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <>
Subject Re: Thoughts about debug-ability of Velocity templates?
Date Mon, 11 Jul 2011 14:13:03 GMT
Definitely a dev topic. :)

Right now Velocity is parsed and turned into an AST (tree of instances
of pre-defined classes), which is directly used for rendering.  To
"compile" templates would mean, parsing them into an AST, generating
new template classes, compiling those new classes and instantiating
one of them.  These classes would also probably all have to live in
custom classloaders in order to be de-referencable for memory
purposes.  This would be an order of magnitude higher complexity, with
a slower initial startup time for unproven (and unlikely) performance
improvement and, i suppose, possible debug hooks.  More work, more
bugs, more trouble.  Never gonna happen.

Most interesting Velocity "events" already spit out errors that
include at least the line, column and reference of the problem or
noteworthy event.  This does not lend itself to setting breakpoints in
templates, but it does provide very direct feedback.  Considering that
we generally frown on overly complex template logic, i concur with
teemu and jian that this is usually quite sufficient.

That said, anyone who wants to offer patches (or even just propose
features in JIRA) that increase the ease and utility of Velocity are
very much encouraged to do so.  Discussions are fun, but most of the
developers around here seem to have scratched their major itches with
Velocity and are not eager to scratch other people's itches.  So,
these days, nothing talks like code.  :)

On Fri, Jul 8, 2011 at 10:21 AM, Rich Wagner <> wrote:
> (I can subscribe to the "dev" list and move this there, but I thought I'd raise this
here first, since debugging is something language users often want.)
> Does Velocity have any support or "hooks" which are designed specifically to support
debugging of the template expansion process?
> I suspect the answer is "No", but I'd appreciate people's thoughts anyway, especially
those of Velocity contributors.
> As a point of comparison:  Consider (say) JSP vs. Velocity.  Velocity templates are
interpreted directly, whereas JSP templates are first translated into Java, which is then
compiled and executed.
> JSP's additional step of translation to Java opens a door to potential JSP debug support
(say as an Eclipse plugin) in that a JSP debugger can translate JSP template source lines
to the corresponding Java lines.  If the user then sets breakpoints on the embedded Java
lines in a JSP template, they can be implemented as normal Java breakpoints, albeit in the
generated Java source, at the matching generated line.  Then breakpoint hits can be translated
in the other direction, back to the JSP template locations.
> (Obviously there's more to it than breakpoint support:  semantics of stepping in JSP
scripts would also need to be defined, ...)
> I'm familiar with this kind of "stuff" because I'm implementing Eclipse-based debug support
for my employer's visual language, and mapping to underlying Java-based debugging is - essentially
- what we're going.
> As a fan of Velocity, I've been musing about whether Velocity is debug-able, or if the
fact it's interpreted closes the door.
> Maybe not necessarily?  For instance, say a user wanted to set a breakpoint on a Velocity
template line containing "$".  And say the user does NOT want to set a breakpoint
in 'call' because there are tons of references to that method: instead, the user wants to
debug the PARTICULAR call at that one Velocity template line.
> I'm wondering if it's crazy - or not - to think:  "OK, maybe there's a single place
in Velocity's implementation where calls are interpreted using reflection.  Maybe a Velocity
debugger could translate the template line breakpoint to a breakpoint in that call interpretation
method.  Then when the breakpoint is hit, the implementation of a Velocity-oriented 'Step
Into' could set a temporary breakpoint in the 'call' method.  This would require the debugger
being able to determine the class of 'obj' and the name of the method -- 'call' -- being interpreted,
since both of those things would be used to set the breakpoint in 'call'.  But the debugger
could get that class and method name information via local variables in Velocity's call-interpretation
> Given the existing implementation of Velocity, is this crazy?  If so, what about the
idea of implementing a Velocity compiler which produces Java?  Other than better performance
of compiled Java, as I said before about debug-ability of JSPs, translating to Java lets a
debugger map between Velocity template lines and Java lines...
> Thanks,
> Rich

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

View raw message