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: AW: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 15:10:09 GMT
On Thursday 12 April 2001 14:31, you wrote:
> On Thu, 12 Apr 2001, Carsten Ziegeler wrote:
> > > Giacomo Pati wrote:
> > >
> > > On Thu, 12 Apr 2001, Carsten Ziegeler wrote:
> > > > Hi,
> > > >
> > > > in addition to the current ToDo-List I would like to discuss
> > >
> > > the following
> > >
> > > > points which I find important for the beta. I think we should
> > >
> > > very quickly
> > >
> > > > agree on this points, if they are useful or if they are just
> > >
> > > overkill, so
> > >
> > > > that we can implement them in the next week or leave them for
> > >
> > > another release.
> > >
> > > > Most of them have been discussed in the last weeks, but we
> > >
> > > haven't had any
> > >
> > > > final result for them.

<snip/>

> > > > 4. ErrorNotifier
> > > >    The "error-pipeline" has a fixed ErrorNotifier. This is not
> > >
> > > customizable
> > >
> > > >    like the other components in the sitemap. For an easier
> > >
> > > error handling
> > >
> > > >    I would suggest a pluggable system.
> > > >    There a two easy possibilities:
> > > >    a) Configuration of all ErrorNotifiers like all other
> > >
> > > components, e.g.
> > >
> > > >       the generators. This would lead to a configuration part:
> > > >       <error-notifiers default="error">
> > > >           <error-notifier name="error" src="..."/>
> > > >       </error-notifiers>
> > > >       and then
> > > >     			<map:handle-errors type="error">
> > > >     				<map:serialize status-code="500"/>
> > > >    			</map:handle-errors>
> > > >    b) The ErrorNotifier currently used is the default and it is
> > > > possible to specify another class with the handle-errors tag:
> > > >     			<map:handle-errors src="...myclass..">
> > > >     				<map:serialize status-code="500"/>
> > > >    			</map:handle-errors>
> > > >    If we agree on this, I will volunteer for it.
> > >
> > > I've proposed this many many month ago. Stefano mentioned not to
> > > over componentize the system. If we agree on componentizing the error
> > > handler I'm +1 on a)
> >
> > Oh, I didn't know that. It might be over componentization, but I found
> > many cases were I really wanted to have another ErrorNotifier and this
> > is currently not possible. We have configurable components everywhere,
> > if we count them (generators, transformers etc.) we have about eight
> > components which can be configured and only one (the ErrorNotifier)
> > which is not. So, this not really a reason over componentization.
> > So, let's vote about solution a).
>
> Another good thing about componentized Errornotifier is that the
> <pipeline> element becomes more sense. You can have different error
> handler for a group of uris which have different management/monitoring
> needs (send mails, SMS, JMX  etc. etc.)

Hi everyone! :)
It's a long time since I've written to this list, I missed you all :-P
I've been very busy on a WYSIWY...hopefully;)G editor for XML (using XSL), 
now I'm sweating into beta.
Anyway, having written the ErrorNotifier stuff I would like to explain 
briefly why it's done that way.
As you can guess I started out thinking of a component for error reporting, 
but Stefano talked me out of it, and I think he is right.
Errors are not IMHO "content", but system messages.
Because of this there is no need to generate a different DTD for any kind of 
error... imagine having 20 different DTDs for errors and keeping track of all 
the stylesheet that go with them... ;)
So I decided to stick to a fixed DTD that can deliver not just errors but 
messages. The DTD (implied) has some fixed tags that give it a type,a name 
and short descriptions; after that a series of added tags for possible new 
data to expose. This is NOT fixed. :)
In fact I decided to create an interface for notifications. If your 
component-code-whatever throws an Exception which implements also this 
interface the ErrorNotifier reads the extra descriptions-data and appends 
them to the XML. 
So you have a fixed DTD with the content you need. IMO this is flexible 
enough.
I also wanted to make this thing resilient, so if it understands that it 
needs to output html directly because cocoon will not process further it does 
so; in C1 I had a tough problem with error messages coming out not correctly 
(difficult to read) because cocoon hadn't yet started up.
So, now that I explained it (I think I should have done it before ;) ) do you 
think it could be ok?
Or maybe you all knew this and I didn't get the point ;-P
If this is comprehensible, can someone put it in the docs please?
If you need a rewrite tell me.

Ciao,
nicola_ken

PS: Can someone finally take away that TODO about hardcoded errors that made 
me write this stuff in the first place!  :-))  (I can't believe it's still 
there!)


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


Mime
View raw message