cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: AW: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 22:33:15 GMT


On Thu, 12 Apr 2001, Nicola Ken Barozzi wrote:

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

Hmm... I don't know. As far as I see it the pipeline starts directly at
the <handle-error> element and thus Actions do not get triggered
anymore.

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

I was not talking about different DTDs. The DTD is ok but the
"sourrounding" actions might vary.

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

As I already said: management responses, not client responsesconcer

Giacomo

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


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


Mime
View raw message