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 20:14:29 GMT
On Thursday 12 April 2001 21:11, you wrote:
> On 12 Apr 2001 nicolaken@supereva.it wrote:
> > 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! :)
>
> Ciao Nicola
>
> Nice reading some lines from you :)
>
> > It's a long time since I've written to this list, I missed you all :-P
>
> That's your problem :) We were always here.

:)

> > I've been very busy on a WYSIWY...hopefully;)G editor for XML (using
> > XSL), now I'm sweating into beta.
>
> Open Source ?

;)

> > 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.
>
> Maybe flexible enough for reporting to the client. But I think other
> needs for errors arise like reporting to a management console
> whatsoever.


I'm sorry, I think I don't get it. Once the error is generated in XML,
can't you process it with all the C2 pipeline stuff?
Can't you trigger actions that report to a console?
AFAIK, Generators should *generate* xml, not send other stuff
to a console. Actions should do it, am I right?
And don't you think that a component-based approach can
make error reporting more difficult to administer with many different
DTDs? Personally I think that worse than having error pages on a site
is having criptic error pages.
Please, could you or anyone describe use-cases which are
impossible or extremely impractical to do with the current model?
Thanks :)

Ken


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