At 2:26 pm +0100 19/3/02, Nicola Ken Barozzi wrote:
>From: "Jeremy Quinn" <[EMAIL PROTECTED]>
>
>> At 11:08 am +0100 19/3/02, Nicola Ken Barozzi wrote:
>> >From: "Jeremy Quinn" <[EMAIL PROTECTED]>
>> >
>> >
>> >> Dear All,
>> >>
>> >> I am totally mystified as to how you are supposed to handle errors in
>> >> webapps built using Cocoon.
<snip/>
Sorry for my late reply, I was teaching yesterday and not supposed to be
doing my email ;) (Some of my students got their first Cocoon websites up,
whoopee!)
>> >Dear Jeremy,
>> > this is a known issue, and basically a worksforme.
>> Ah, can I redirect on error internally and still have the original Request
>> available?
>
>Redirects are not allowed IIRC, or shouldn't be.
>They can cause loops, because where you redirect can have errors too.
Hmm, redirect to a different pipeline that reads the request data as text
this time, sends it back to the user as a form, using
'disable-output-escaping' so the mal-formed XML comes back intact. Then you
loose the error message .... hmmm
>> Basically I am trying to send sensible response when StreamGenerator
>throws
>> exceptions on mal-formed XML.
>
>Well, there shouldn't be malformed XML being processed.
That is the very point I am wanting to make.
In a publishing engine, this is indeed the case. In a webapp, not so sure,
in an online editor, no choice mate, we need to check well-formedness
somewhere!
Anyone got any well-formedness checking javascripts? ;)
>> >If you have a better solution, please commit it, we are all waiting.
>>
>> Yea, sorry if I was rude !
>> I accept what you say ..... I think that the current error-handling is ok
>> for publishing, but not good enough for webapps ......
>
>Well, AFAIK, it's not enough yet, but getting better.
>I haven't had much help on it, and little feedback. I'm happy we can discuss
>about how to make it become better :-)
Thanks ..... one idea is that we might like the concept of different error
reporting for different users.
ie. during development, a Java developer would have all stacktraces
reported, an XSLT developer may have their dev environment set up to just
report Parsing and Transformation errors. A production server would have
all 'technical' error reporting turned off and would just send 'polite
messages'.
Another issue (I have not my head around yet) : can we report the error
'inline' somehow, instead of as a second 'document root', then people who
need to, could do something useful with it.
To see what I mean:
Grab <slash-edit/> from the scratchpad, fire it up. Using the 'Alpha'
Editor, make new page, add mal-formed XML (<br> would do), 'Preview' the
changes and Boom, you get two sequential pages! (OK, so I can make the
<slash-edit/> bit look better ;), but it was still a shock to see what
happens ;)
Another idea could be to say: this particular sitemap pipeline is a
"buffering error-collection pipeline" because this is a crucial part of my
webapp that /might/ throw exceptions that I want to adapt to.
>> Has anyone got examples they can send me of how they have implemented
>> error-handling in the sitemap, the samples are not very revealing .....
>
>To be honest, there's nothing much to it.
So no one documents it ;) (Sorry, I know it is as much my responsibility as
anyone else .....)
>In handle-errors you have a sitemap ther has a fixed Generator.
>You can use Actions, Transformers and a Serializer, like in other sitemaps.
What confused me I guess, was where the error report came out.
Plus I tried several times to put <map:handle-errors/> inside separate
<map:pipeline/>s and got compile errors and hangs.
>IMHO StreamGenerator may not be right for the job. If there is an error in
>the xml it happens what you saw.
>But it never happens with normal requests, and it's with those in mind that
>the error handling, as it is now, was created.
I understand.
I am fully prepared to write a new Generator that parses Requests and does
not throw exceptions. I was just trying to see if I could get away without
it ;)
>Please tell me what you want to do as a bigger picture so I can help you
>with a possible solution.
I never really needed to worry about what the error handlers did before,
like most people, all my errors were removed before publishing my sites.
It is only since starting <slash-edit/> and beginning to look to see what
was actually being sent that I got a bit shocked at the result.
The <slash-edit/> sitemap is broken down into small snippets that call each
other internally. If these internal pipelines could report errors in a
controlled way, it would be much easier to control the response.
Thanks for your help and effort.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
