cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nicola...@supereva.it ()
Subject Re: Re: AW: [C2]: ToDo - List for going Beta
Date Fri, 13 Apr 2001 08:08:55 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.

Hmmm... we should take a look at the code...
Do you think that, if it were possible, it would be more sensible?

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

Ok, my worry is that breaking the ErrorNotifier constraints things could get wild.

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

Yes, I do understand this, but my concern is about not throwing away the fixed DTD concept
that I find usefull...
...maybe we should see what we mean by ErrorNotifier componentization.  
Basically AFAIU we need to send errors to classes other than the pipeline for management purposes.
This means that we should make it possible for other classes to be hooked into ErrorNotifier
and recieve the error events they registered for.
I'm ++1 for this.
I don't know actions very well, but isn't this their role? 

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


-----------------------------------------------------

messaggio inviato con Freemail by superEva
http://www.supereva.it

-----------------------------------------------------


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


Mime
View raw message