cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Sitemap error-handling [was : [VOTE] directly setting variables in sitemap]
Date Tue, 04 Dec 2001 17:09:29 GMT


Nicola Ken Barozzi a écrit :
> 
> ----- Original Message -----
> From: "Nicola Ken Barozzi" <barozzi@nicolaken.com>
> To: <cocoon-dev@xml.apache.org>
> 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" <sylvain.wallez@anyware-tech.com>
> To: "cocoon-dev" <cocoon-dev@xml.apache.org>
> Sent: Tuesday, December 04, 2001 10:13 AM
> Subject: Sitemap error-handling [was : [VOTE] directly setting variables in
> sitemap]
> 
> >
> > nicolaken@supereva.it 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
> > > <xml-cocoon@nicolaken.com>                             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.

You're right : a new pipeline is started in <handle-errors> and you can
add whatever sitemap construct you want but a generator (the special
ErrorNotifier generator is set by the engine).

But you can't do anything in this pipeline that depends on the error
contents : the exception is passed to the ErrorNotifier and isn't
available in any of the match/act/select that you can put in this
pipeline.

> > 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.

Nope : it builds a Notification with the Exception and uses Notifier to
produce XML out of it.

> All exceptions in Cocoon should implement that interface, so
> to be able to provide all the extra stuff you are talking about.

Sorry, but I find Notifiable too constraining in what can be expressed
using it. While this is good if we can't trigger error-handlers by
specific exception types, this will be very limiting if we introduce
this feature.

For a use case, look a my previous post in the thread "[VOTE] directly
setting variables in  sitemap" where I talk about ExplainableException
to see what I mean.

Sylvain

> 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
> <xml-cocoon@nicolaken.com> Paul Simon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message