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
972-883-2157
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<richmwag...@hotmail.com> 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 "$obj.call()". 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 method..."
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: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
