From: "Jeremy Quinn" <[EMAIL PROTECTED]>
> 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'.
It's possible, the framework is all there, you just need to write the
stylesheet.
Now I understand that *nobody* wants to care about doing this, because the
cocoon webapp example is instead used as a template.
Because of this, I started refactoring the examples to make it easier to get
a bare bones Cocoon webapp.
I will make more examples and stylesheets for as soon as the freeze is over.
> 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.
Of course.
Since the handle errors *is* a pipeline, you can output what you want, even
plain text.
> 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 ;)
It's normal, and even useful to the febugger of the app to have this
happening.
You see right away what went wrong.
But handle errors is only for *real* errors, not for predefined program
states.
Incorrect xml is part of the possible logic of your program, and you
shouldn't handle it in this part of the pipeline, because of the problems
outlined in previous mails.
As you see, the current implementation prevented you from misusing the
concept, and IMHO this shows good design.
> 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.
The possibility of setting per-pipeline buffer size will be addressed in the
next dev cycle.
> >> 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.
? Each pipeline can have its own handle-errors, and some samples already
show this.
See the sub/ samples for a hint.
> >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 ;)
The request processing should be done (and usually is) with objects rather
than in the pipeline.
Your needs are new to me, and highlight a possible deficiency in the
handling of xml coming in.
If we SAX away with it, we go in handle-errors.
If we parse before, we do it twice.
IMO this is the point.
> >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.
This is a *very* interesting point.
You are using sitemaps as flowmaps.
Flowmaps should solve your problems but...
yes, we need to think of how to handle errors with flowmaps, remembering
that we should be able to make
sitemap->flowmap->sitemap->flowmap->sitemap...etc.
Hmmm......
> Thanks for your help and effort.
Thank you for slash edit.
I think it's very cool :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
