I don't like this and find it hacky. Using println in the flowscript is a useful technique and as I said I use it. But introducing official println equivalents all over the place will lead to floods of messagesI like this very much!How about adding a "message" attribute to ProcessingNode, e.g: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?
I'd like to second that.
Besides I think we are mixing debugging with error reporting.
For error reporting we don't necessarily need a println. As long as the exception carries all needed information we can display something useful inside the browser and/or the log.
This came up once at a Cocoon Stammtisch in Frankfurt when we were talking about XSP debugging and error reporting: we could introduce an exception that swallows SAX events so we can store semantically useful information inside the exception. The events could then be put back into the error pipeline. A stylesheet could to the rest.
...or we have a couple of specific exceptions that have a toSAX() method...
Anyway ...I'd prefer not to clutter the sitemap with println statements.
cheers -- Torsten
