I don't think anyone is suggesting that there shouldn't be support for a source level debugger. But that is a large project, IMO. And having the ability to do "println" debugging doesn't preclude it.

My $0.02,

Chris

Sylvain Wallez wrote:

Stefano Mazzocchi wrote:

On 12 Jan 2004, at 18:18, Christopher Oliver wrote:

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



I like this very much!


+1



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 messages scrolling on the console or filling the logs. Wouldn't a unified debugger for the various languages cooperating in Cocoon (sitemap, jxtemplate, woody form definitions, etc) be more useful?


-0.9

Sylvain



Reply via email to