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
