Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough to build a debugger?
The runtime part of the debugger can be a optional listener in add/popStackFrame which suspends the execution when a breakpoint is encountered (detected using the stack element's location).
And we can also associate an additional object to a StackTraceElement that will give access to the variables in the element's scope. This will be e.g. an InvokeContext for the TreeProcessor or a [JXPath|Jexl]Context for JXTemplate. This allows the debugger do display and even modify the variables that drive the current request's execution.
Without getting into all the details, I think a proper API for a global debugger would require quite a bit more infrastructure than what you're suggesting.
Since AFAIK, you've written the Rhino debugger, can you enlighten us on the required infrastructure?
Also with the fast edit - reload - test cycle provided by Cocoon, "println()" style debugging seems to work quite well. A source-level debugger is mainly required when the development turnaround cycle is long (e.g. J2EE apps). For example, although Rhino has a JavaScript debugger, I rarely use it because println() debugging is usually more efficient.
I do the same for flowscript. But how can we insert a println() in a sitemap?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
