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