----- Original Message -----
From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 04, 2001 1:34 PM
Subject: Re: Sitemap error-handling [was : [VOTE] directly setting variables
in sitemap]
----- Original Message -----
From: "Sylvain Wallez" <[EMAIL PROTECTED]>
To: "cocoon-dev" <[EMAIL PROTECTED]>
Sent: Tuesday, December 04, 2001 10:13 AM
Subject: Sitemap error-handling [was : [VOTE] directly setting variables in
sitemap]
>
> [EMAIL PROTECTED] a écrit :
> >
> <snip/>
> > >
> > > Time to introduce an idea I had recently. For now, we only have two
> > > types of map:handle-errors : 404 (ResourceNotFoundException) and 500
> > > (all other Exceptions). What about extending this to allow specific
> > > exception types to trigger specific map:handle-errors ? This would
allow
> > > the following constructs :
> > >
> > > <map:handle-errors
> > >
exception="org.apache.avalon.framework.configuration.ConfigurationError">
> > > <map:act type="warn-admin-of-bad-config"/>
> > > <map:transform src="configError2html.xsl"/>
> > > <map:serialize type="html"/>
> > > </map:handle-errors>
> > >
> > > <map:handle-errors
> > > exception="java.lang.security.AccessControlException">
> > > <map:transform src="ace2html.xsl"/>
> > > <map:serialize status-code="403"/>
> > > </map:handle-errors>
> > >
> > > Thoughts ?
> > >
> >
> > Well, in the xml of the error you have quite a lot on info you can use
to decide what to do without changing the sitemap.
> > You could use a special selector that selects on the content of an
"error namespace" tag to select the appropriate action, or a series of
transformers like the log transformer (passthrough) that basically does the
same thing.
> > I don't see the need of new semantics.
> >
> > Nicola Ken Barozzi These are the days of miracle and wonder...
> > ...so don't cry baby, don't cry
> > <[EMAIL PROTECTED]> Paul Simon
>
> I'm afraid this won't work : the XML describing the error is only
> available at pipeline processing time, that is _after_ all selectors,
> actions and the like have been executed.
Before handle-errors the XML describing the error is not there,
after you should have another pipeline to spit it out, and if
this still doesn't work, a generic html error comes out.
In fact in handle-errors, in the current sitemap, you have a Transformer.
If in handle-errors isn't a special pipeline where you can act, select,etc
I think it should become one. This is how it was intended.
> Also, continuing my proposal, it would be good to be able to specify the
> error notifier (the special generator for exceptions). For now it is
> hard-coded to use the Notifier which does a nice job for most
> exceptions. But we use here some smart exceptions which carry a lot of
> useful information and are XMLizable, and I'd like to be able to set the
> generator in handle-errors to process this information.
Sorry, I don't get it.
The ErrorNotifier checks is an Exception is instanceof Notifiable;
if so il spits out all extra descriptions using that interface.
All exceptions in Cocoon should implement that interface, so
to be able to provide all the extra stuff you are talking about.
This hasn't been done because when I was starting to ask all to do it and
"enforce" it by adding to the error the phrase "Extra descriptions are not
available because the programmer was too lazy to put them in" ;-)
I had to leave the list. So I guess it's my fault not making this clear
enough.
Implementing this interface you don't need to make a Generator to
show the extra descriptions, and your XML is always the same -> you can
easily have standard stylesheet for all errors and are guaranteed that the
error notification gets generated.
PS. I've just taken a look at the c2 src: Notifiable is called Notificable,
I thought it was changed. I guess it's time I give it another check.
Anyway, here is the interface; the extra descritions are the point.
Now that I remember I proposed this stuff to the Avalon guys when they
were writing the CascadingException stuff and they convinced me that
it wasn't general enough for a generic exception (too rich)... but I forgot
to make Notifiable forcibly Cascading...
...don't you think a Notification should be cascading?
Anyway, the original-original idea was to use the error namespace xml
inline to report xalan warnings and such.
Suggestions?
public interface Notificable {
/**
* Gets the Type attribute of the Notificable object
*/
String getType();
/**
* Gets the Title attribute of the Notificable object
*/
String getTitle();
/**
* Gets the Source attribute of the Notificable object
*/
String getSource();
/**
* Gets the Sender attribute of the Notificable object
*/
String getSender();
/**
* Gets the Message attribute of the Notificable object
*/
String getMessage();
/**
* Gets the Description attribute of the Notificable object
*/
String getDescription();
/**
* Gets the ExtraDescriptions attribute of the Notificable object
*/
HashMap getExtraDescriptions();
}
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<[EMAIL PROTECTED]> Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
