cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2] (hopefully) last sitemap major changes
Date Tue, 04 Jul 2000 11:46:50 GMT
Giacomo Pati wrote:
> 
> --- Stefano Mazzocchi <stefano@apache.org> wrote:
> > Giacomo Pati wrote:
> >
> > > > 5) added the notion of "error handling" (which includes metaevents
> > > > handling) as such
> > > >
> > > >  <map:pipeline>
> > > >   <map:match ...>
> > > >    ...
> > > >   </map:match>
> > > >   <map:handle-errors>
> > > >    <map:transform src="./style/error-page2html.xsl"/>
> > > >    <map:serialize/>
> > > >   </map:handle-errors>
> > > >  </map:pipeline>
> 
> And there is only one <handle-error/> per <pipeline>?

Yes.

If you need different error-handling behavior, use choosers inside.
 
> > >
> > > First some glossary:
> > > - a pipeline is the block enclosed by <map:pipeline> and </map:pipeline>
> > > - a pipe is a assebled chain of a generator, transformers and a
> > > serializer choosen by matchers, choosers, mounts and/or resources.
> > >
> > > Do I understand it right, that the hole
> > > <map:handle-errors></map:handle-errors> block is a pipe for itself
with
> > > the surrounding pipeline (excluding the handle-errors block) as its
> > > generator.
> >
> > Yes, I don't like with your terminology entirely but I don't have better
> > names.
> >
> > > Every component (including matchers, chooser, etc.) of the
> > > pipeline can fire event to that handle-error block and as soon as an
> > > (maybe special) Exception is thrown the handle-errors block becomes the
> > > active pipe which writes to the OutputStream instead of the failing
> > > pipe.
> >
> > No, no. Each component has access to two event streams, one is the SAX
> > stream routed by the sitemap to the other component, the other one is
> > the tracing stream.
> 
> Even if there is no <handle-error/> or <hanlde-trace/> respectively?

Well, pass a dummy one with empty methods. (hotspot will optimize the
calls and the overhead will be negligible.
 
> I see some cases where a serializer fires events to the trace stream before a
> generator/transformer does (because of the semi parallel mechanism of the assembled sitemap
> components). Does this gives us any problems (I personaly do not know because I've not
made many
> thought about that trace/error streams)?

??? when?
 
> > > There is a need to extend existing Interfaces or introduce new ones to
> > > have access to the ContentHandler of the handle-errors block.
> >
> > Sure we have to extend existing interfaces since we must provide hooks
> > to send tracing metaevents to this pipe.
> 
> Something like:
> 
>     public interface Traceable {
>         public void setTraceContentHandler (ContentHandler ch);
>     }
> 
> and if a component implements Traceable it gets a ContentHandler to the tracer at instantiation
> time if there is any. 

Yes, exactly. Keep in mind that using SAX for traces is too much. We
should write our own TraceHandler with a few methods and stick with
them.

It's not the component job to know the XML schema the traces will be
thrown with.

So

 g -(data)-> t -> s
 +-----------+----+-(trace)-> tracer -> t -> s

Where "tracer" is responsible for translating trace events into SAX
events (and you can plug your own to define your own tracing XML schema)

> This is similar to the interface Configurable?

You mean, it uses the "inversion of control" principle? yes
 
> >
> > Now I wonder: should we have both
> >
> >  <pipeline>
> >   ...
> >   <handle-errors>
> >   </handle-errors>
> >   <handle-traces>
> >   </handle-traces>
> >  </pipeline>
> 
> Maybe I lost some points but where is the stream for <handle-errors/> and <handle-traces/>
finaly
> going to?

Sorry, the above needed more dots 

  <pipeline>
   ...
   <handle-errors>
    ...
   </handle-errors>
   <handle-traces>
    ...
   </handle-traces>
  </pipeline>

> > or we can keep this together?
> >
> > NOTE: if we keep them together, we can use different namespaces to
> > indicate errors and traces, but maybe two different schemas are better?
> > What do you think?
> >
> > > > 6) added the notion of "views" and pipeline "labels".
> > > >
> > > > for example
> > > >
> > > >  <map:view name="content" generate-from="content">
> > > >   <map:serialize type="xml"/>
> > > >  </map:view>
> > > >
> > > >  <map:view name="schema" generate-from="content">
> > > >   <map:transformer type="schema"/>
> > > >   <map:serialize type="xml"/>
> > > >  </map:view>
> > > >
> > > >  ....
> > > >
> > > >   <map:label name="content">
> > > >    <map:generate src="./file/document.xml"/>
> > > >   </map:label>
> > > >   <map:transform src="./style/doc2html.xsl"/>
> > > >   <map:serialize/>
> > > >
> > > > where it can be viewed as
> > > >
> > > >  g -(content)-> t -> s   [normal view]
> > > >         +-----> t -> s   [schema view]
> > > >         +----------> s   [content view]
> > >
> > > I see a lot of new Interfaces introduced getting that to work. And also
> > > some changes to the existing ones. You too?
> >
> > Yes, the new interface is TraceHandler and must be made available to all
> > pipeline components.
> 
> Oh, I've thought it should be the other way around (see above Interface Traceable)?

"might be available" doesn't necessarely mean "the component asks for
it".

I agree that the way to go is using inversion of control and push the
TraceHandler if the component implements Traceable.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message