Christopher Oliver wrote:
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?
I'll try to write up something about this when I have a little time.
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?
How about adding a "message" attribute to ProcessingNode, e.g:
<map:match pattern="page/*">
<map:generate type="jx" src="screens/{1}.xml" message="match is page/{1}"/>
which would output something like
sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is page/getNumberA.html
- Chris
