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
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.
Replace "sitemap" with "my sitemaps": some people might like that... but they are not forcing you to have them.
Come on ...this is not an argument. We quite often abandoned some ideas that what were useful (to a certain degree) because we assumed FS or because we had some other concerns ...although noone was forced to use them!
What you say above is like saying "I don't like cocoon.log() because I would rather not clutter the flowscripts with println statements".
Well, you got a point. Maybe it's my perception of the sitemap that makes me feel differently about the use of logging facilities inside
flowscripts. I see the sitemap more as a configuration while
flowscript is a programming language from my POV.
[ Besides I still think *println* is bad in flowscript although it might be (well.. *is*) super for development. But having e.g. an optional flowscript console would be much better IMO. Otherwise: if we start using println... which components may use System.out which may not? ...this weakens a clean approach IMO: none should use println ]
Just like there are views that I use during developers but don't use in production, I could totally write a simple XSLT stylesheet that strips off the <map:log> tags from the development sitemaps or turns them into comments.
You are not proposing to introduce sitemap pre-processing, are you? You mean doing it by hand?
I'm still +1 to <map:log> and see no real reason why not to do it.
All I am asking is ...do we really need it?
[feeling hacky is not a real reason if there is no alternative proposed and the need is felt...
I am just wondering ...when do you need it? Usually I'd need it if something goes wrong. How often is something wrong in your sitemaps and you don't get an exception?
...I am totally +1000 adding that wonderful cocoon stack trace to our exception handling.
Just some RT ...what about a development mode (here comes the running mode again;) where you get a sitemap console and flowscript console. In the sitemap console you could see the stack trace of the last request ... in the flowscript console the log from the flowscript.
> and don't tell me that <map:act type="log"> is
less hacky]
Be sure I won't :)
cheers -- Torsten
