cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: Sitemap error-handling [was : [VOTE] directly setting variables in sitemap]
Date Tue, 04 Dec 2001 17:33:51 GMT

----- Original Message -----
From: "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>
To: <cocoon-dev@xml.apache.org>
Sent: Tuesday, December 04, 2001 6:09 PM
Subject: Re: Sitemap error-handling [was : [VOTE] directly setting variables
in sitemap]


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

I gave a quick look at the source code and I think you are correct.
This is not how I intended it to be... as it is now Notificable is
basically useless...

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

See that mail...

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

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


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


Mime
View raw message