cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject Re: [C2] (hopefully) last sitemap major changes
Date Tue, 04 Jul 2000 06:56:01 GMT

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

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

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

> > 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. This is similar to the interface Configurable?

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

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

Giacomo

=====
--
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Mime
View raw message