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 Sat, 01 Jul 2000 08:17:11 GMT
Giacomo Pati wrote:

> > 3) increased redirection capabilities
> >
> >  <map:redirect-to uri="..."/>
> >  <map:redirect-to resource="..."/>
> >
> > a "resource" being a
> >
> >  <map:resource name="...">
> >
> > where the "name" attribute is the ID and "resource" is the IDREF.
> 
> We have still type= and name=. As there were no comments on it I thought
> you would make them consistent. But this didn't happend so I vote for
> using name= as IDs and type= as IDREFs.

Good point, I like the pattern. +1
 
> >
> > 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>
> 
> 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.
 
> 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.

Now I wonder: should we have both

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

> >
> > The sitemap allows each "producing" component (generators and
> > transformers) to attach "default labels" to these components so that
> >
> >   <map:label name="content">
> >    <map:generate src="./file/document.xml"/>
> >   </map:label>
> >   <map:transform src="./style/doc2html.xsl"/>
> >   <map:serialize/>
> >
> > is totally equivalent to
> >
> >   <map:generate src="./file/document.xml"/>
> >   <map:transform src="./style/doc2html.xsl"/>
> >   <map:serialize/>
> >
> > if the "parser" generator (which here is default), has attached as
> > default label "content"... such as in
> >
> >   <map:generators default="parser">
> >    <map:generator type="parser" src="..." label="content"/>
> >   </map:generators>
> >
> > this should allow us to use sitemaps for simple views (such as content
> > or schema) without introducing too much sitemap-creation overhead and
> > reduce readability with a bunch of <label> tags.
> 
> I don't think I have that all grasped but my intuition says it will come
> on the right way.

Thanks for your trust :)
 
> > This, for me, it's the last working draft for Cocoon 2.0... it may not
> > be perfect, but it covers up everything I wanted to cover with this
> > release.
> 
> <snip/>
> 
> > So, I consider it feature-frozen from now.
> >
> > Let's polish it and let's rock and roll implementing it :)
> 
> Uff, finaly. Now we can implement that monster leisurely :)

it shouldn't be that bad... we already thought about most of the problem
we could have come out with during implementation...

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