velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barbara Baughman <>
Subject Re: Thoughts about debug-ability of Velocity templates?
Date Mon, 11 Jul 2011 15:29:15 GMT
I agree that debugging Velocity now is very simple.  Just render the 
template and see if it looks right.  Check it using all possibilities 
for if statements.  If you like the result, then it passes.  No debug 
program is going to tell you if the result is what you wanted or 
expected.  The Velocity log will indicate anything that the template 
could not render, with very adequate debugging information.

I also love having a non-compiled screen view.  To change it, I just 
change the template and the view immediately changes.  (I know that not 
all implementations do this, but I find it very convenient.)  It really 
shortens development time when things don't have to be completely 
recompiled and restarted for each change.

I also agree that it is often better to put code that is complex in a 
JAVA method that can be debugged using traditional methods, and then 
call that method from Velocity.

I seem to recall that one of the goals of the Velocity design was a 
system for rendering that required minimal programming skills, so web 
designers could be web designers and programmers could be programmers.  
Adding the complexity of compilation would seem to defeat that goal.

Barbara Baughman
Systems Analyst
Information Security

On 7/11/11 9:13 AM, Nathan Bubna wrote:
> 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:

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

View raw message