cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: ToDo - List for going Beta
Date Tue, 17 Apr 2001 06:05:40 GMT
> Von: nicolaken@supereva.it [mailto:nicolaken@supereva.it] 
> 
> >
> 
> >
> 
> >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.
> 
Yes, you're right - the DTD for the error should be fixed.
What about creating an interface NotificationReceiver (or however we
call it)? Then it would be possible to configure components which
implement this interface and receive notifications for each error.

This might be handier and less errorprone as the many ErrorNotifiers
approach.

Carsten

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


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


Mime
View raw message