i would just enable any debug prints in velocity and put in some additional debug prints in my templates. but i am lazy and don't really start the debugger these days..
2011/7/8 Rich Wagner <richmwag...@hotmail.com> > > (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 > >
