----- Original Message ----- From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: "cocoon-dev" <[EMAIL PROTECTED]> Sent: Thursday, January 03, 2002 4:18 PM Subject: Re: Refactoring and correction of error notification
>
>
> Nicola Ken Barozzi a écrit :
> >
> > ----- Original Message -----
> > From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, January 03, 2002 12:24 PM
> > Subject: Re: Refactoring and correction of error notification
> >
> > > Nicola Ken Barozzi a écrit :
> >
> <snip/>
> > >
> > > OK. So I propose system-wide categories. They imply more development in
> > > the Cocoon core, but provide the cleanest way for filtering.
> >
> > +1
> > If you can work on this, I'll take care of the output part (see below).
>
> I'll make a proposal soon. In order for it to be both speedy and
> available from every place in the code, I think we will need a component
> with a set of static accessor to static loggers. I know static variables
> are a bad thing, but looking up a regular component will certainly kill
> performance.
Hey, now why not use log4j?
It has static accessors... I don't understand why Avalon made his own version.
It stopped the testlet stuff because JUnit was way ahead, why then not use log4j?
What is needed that it cannot provide?
Ok Mr. Donald, don't hit me too hard on this ;-P
> The system-wide categories I foresee are (please add your own) :
> - deprecated features
- development (the *with* part)
> > > > <snip/>
> > > > > >
> > > > > > A Map has OBJECTS.
> > > > > > You CAN make your Builder that checks for XMLizable and outputs that to
> > > > > > extra or whatever. And extra is intended to have anything inside.
> > > > >
> > > > > Am I biased by the current implementation ? SimpleNofiyingBean only
> > > > > accepts Strings as extra descriptions
> > > >
> > > > Yes, because it's... well... simple ;-)
> > >
> > > So we will need a... well... less simple implementation !
> >
> > :-))
> >
> > Well, I did not prefer having a more complex one, because I prefer that objects
>implement the interface directly. This at least was the original intention that made
>me write a ...simple ;-) implementation.
> > Why do you need a more complex one?
> > I'm not against it, mind me, but if I know the purpose better I can write it with
>more "grano salis".
>
> With the non-fixed generator, I guess this may not be actually needed.
> So let's delay this until we have a real need for it.
Ok.
> > > > > >>> Ken: And
> > > > > >>> give me an example that explains how the current proposal is clearly
> > > > > >>>inadeguate in solving the problem.
> > > > > >>>
> > > > > >
> > > > > > This question is in the snippet and here again.
> > > > > > I want facts, not words. What can't you do?
> > > > >
> > > > > I can't set my own generator in <handle-errors>. I'm happy with a fixed
> > > > > DTD for exception reports to the user. But I would like to be able to
> > > > > generate something else than the error DTD in some branches of the
> > > > > "error-type" select statement.
> > > >
> > > > Why?
> > > >
> > > > > This what my example with several <handle-errors> was all about : each
> > > > > branch has a different generator, the "notification" generator being the
> > > > > one that issues the standard error DTD from the Notifying object.
> > > > >
> > > > > Finally, (my thoughts cleaned up with this discussion), this is not the
> > > > > fixed DTD I am criticizing, but the fixed generator.
> > > >
> > > > A Generator translates "information-entities" in XML. When the
> > > > "information-entitiy" (Notifying and Env) are defined and the DTD is
> > > > defined... the Generator is defined. If you want to "filter" the Notifying,
> > > > you can make your own Builder. The Builder is basically a filter that gives
> > > > you the flexibility that multiple Generators have without the possible
> > > > varying DTD.
> > > > What you need, I think, is to be able to decide the mapping between the
> > > > Notifying and the DTD. But the notifying and the DTD basically mimic the
> > > > same structure; the Builder can filter and transform your Notigying to your
> > > > needs.
> > >
> > > Once again, the use case is not filtering the Notifying contents, but
> > > generating something completely different, this generation being
> > > triggered by the fact that an exception occured and that some selector
> > > directed to that generator.
> > >
> > > In that case, the information-entity isn't defined : the Notifying is
> > > just additional data which complements the environment and object model
> > > to _choose_ the content, i.e. direct pipeline assembly, as matchers and
> > > selectors do in regular pipelines.
> > >
> > > Let's consider a very common use case : most sites display nice pages
> > > when a requested URL doesn't exist instead of the raw "404-not found"
> > > server message.
> > >
> > > The below sitemap snippet shows an implementaton of this behaviour : the
> > > "notyfing-type" selector selects a branch depending on the value of
> > > Notifying.getType(). When a resource isn't found (type
> > > "rsrc-not-found"), the page to display uses the same content DTD and
> > > pipeline definition than other parts of the site. In this example, a
> > > standard page is a resource that aggregates page content and some common
> > > elements.
> > >
> > > <map:resource name="site-page">
> > > <!-- standard layout of the site -->
> > > <map:aggregate element="page">
> > > <map:part src="top-menu.xml" element="top"/>
> > > <map:part src="{page}" element="content"/>
> > > <map:part src="sidebar.xml" element="side"/>
> > > <map:aggregate/>
> > > <map:transform src="site-page2html.xsl"/>
> > > <map:serialize/>
> > > </map:resource>
> > >
> > > <map:handle-errors>
> > > <map:select type="notifying-type">
> > >
> > > <map:when test="rsrc-not-found">
> > > <!-- display the not-found page -->
> > > <map:call resource="site-page">
> > > <map:parameter name="page" value="not-found.xml"/>
> > > </map:call>
> > > </map:when>
> > >
> > > <map:otherwhise>
> > > <!-- generic formatting of the error DTD -->
> > > <map:generate type="notifying"/>
> > > <map:transform src="error2html.xsl"/>
> > > <map:serialize/>
> > > </map:otherwhise>
> > >
> > > </map:select>
> > > </map:handle-errors>
> > >
> > > This example may seem complex (a resource with an aggregation), but I'm
> > > sure it corresponds to real-world use cases.
> >
> > Ah, now I understand :-)
> > Indeed the example is very very clear, thank you.
> > <mind state="thinking">mumble...mumble...</mind>
>
> Pheeew ! I finally succeeded in making my thoughts clear :-)) It's
> sometimes not that easy for two people with different experiences and
> native languages to understand themselves in a third language ;)
:-) I think that we both make too many assumptions on what the other "should" know of
:our problems.
IMHO the best way to overcome this is to always acclude examples in use-cases and code.
> > > > <snip/>
> > > >
> > > > > >>We should clean up existing stuff by reducing the number of logs, output
> > > > > >>useful and meaningful messages, structure the log hierarchies, and if
> > > > > >>needed define system-wide loggers for categories orthogonal to component
> > > > > >>functions (deprecation is an example of this).
> > > > > >>
> > > > > >>So -1 for a list of Notifying in the object model.
> > > > > >>
> > > > > >>My opinion is that when an exception occurs while handling a pipeline,
> > > > > >>only one object representing the error should be available in the object
> > > > > >>model, and only in the <handle-errors> part of the pipeline.
> > > > > >>
> > > > > >
> > > > > > I agree. +1
> > > > > > In fact the patch is not based on many Notifying objects in the
> > > > objectmodel,
> > > > > > this is just a small part of it. To be honest I don't really care that
> > > > much
> > > > > > if it becomes only one Notifying like it was in the first patch version.
> > > > I
> > > > > > put it there as a "hack" to see how it could work out and how the
> > > > dev-list
> > > > > > reacted, and my concerns in fact were more than a feeling.
> > > > > > Giacomo applied the patch, so I'm going to send a patch to it to make it
> > > > > > only one; if you can apply it right away I guess your -1 goes away.
> > > > >
> > > > >
> > > > > Patch applied. My -1 is also pushed away because the discussion has some
> > > > > very constructive results.
> > > >
> > > > :-)
> > > >
> > > > > > But the problem it tried to solve (by creating others as you correctly
> > > > > > demonstrated) is still there.
> > > > > > Let's concentrate on the only part that's left to discuss: good logging.
> > > > > > I would say that other issues are resolved, don't you think?
> > > > >
> > > > > Mostly : clean logging, single Notifying, single <handle-errors>. The
> > > > > last remaining point is about non-fixed generator (didn't said DTD) in
> > > > > <handle-errors>.
> > > >
> > > > The problem is that you can't give flexibility of changing Generator while
> > > > fixing a DTD. IMO the Builder should do it. Comments?
> > >
> > > See the sitemap snippet above. Fixed DTD is OK when the content is the
> > > Notifying. But you don't always want the Notifying as the content.
> >
> > In other words you don't always want use the notification content, right?
>
> Right.
>
> > It's not that the notification content is not enough for you (as I originally
>though you meant), it's that you want to use a completely different content, with no
>knowledge whatsoever of what happened before!
>
> Totally right : in that case the notification is just an event for
> triggering <handle-errors> and some data used by a selector.
>
> > I understand, and your point is sensible.
> > My concern is that giving the users freedom to use custom Generators in
>handle-errors, they bypass the fixed DTD alltogether, which nullifies basically its
>benefits.
> > How do we solve this?
> > Maybe allowing only map:call resource (like in your example; as you see, no
>Generator with access to NOTIFYING-OBJECT is there) and resetting all the previous
>objectModel could do it.
> > What do you think?
>
> People are lazy by nature. So why would they write
> yet-another-NotifierGenerator when Cocoon already provides one ?
Don't be so sure of this.
Everyone -I mean everyone, really ;-) - that didn't know how to do something with
Cocoon told me "How can I write my generator to do this?".
> And if
> they finally decide do write one, then it's their responsibility to
> write the corresponding stylesheets.
It's always their responsibility anyways.
But you write something one day, and the day after I have to maintain it ;-)
Or worse: I need to integrate two Cocoon apps written separately.
Brrrrr... ;-)
> So I would not limit to map:call, since soon people will claim "I don't
> want to use a resource. Why can't it put a <map:generate> ?"
"Limit" is the right word. I *want* to limit.
Making handle-errors a complete sitemap can lead easily to bad programming practice.
I fear the day someone will ask me to have an explicit handle-errors inside of
handle-errors!
So, for what my vote counts (0 Kelvin) I'm -1 on it.
I think it breaks the contract that has been there in Cocoon of a fixed DTD.
Or use the NotifyingGenerator or a resource.
I don't want nested handle-errors.
<snip type="one of many"/>
> > > >
> > > > > My thoughts about it is a special LogKit LogTarget that buffers
> > > > > LogEvents for a request and a special generator that turns these events
> > > > > to XML. The information put in LogKit's context map (see above) is the
> > > > > key to per-request event filtering.
> > > >
> > > > As for the Generator, isn't there something that logs in XML. How much use
> > > > can come from that?
> > >
> > > Checkout org.apache.cocoon.util.log.XMLCocoonLogFormatter. It outputs
> > > XML as text, but the DTD good be a good starting point.
> >
> > Yes, thank you, I've seen it.
> > I will work on it in my spare time and reasonably finish it over this weekend.
>
> Wow, that's quick !
Ok then, next week ;-)
Ken
--
Nicola Ken Barozzi [EMAIL PROTECTED]
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
smime.p7s
Description: application/pkcs7-signature
