velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From teemu kanstren <tkanst...@gmail.com>
Subject Re: Thoughts about debug-ability of Velocity templates?
Date Fri, 08 Jul 2011 21:49:19 GMT
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 <richmwagner@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message