You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/07/02 11:27:37 UTC

AW: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation I18nTransformer.java TraxTransformer.java

I just changed the semantics of the content aggregation. Now, if
you want to aggregate pipelines, you have to explicitly
use the cocoon:// url.

This enables aggregating xml from different sources, e.g.
aggregating several xml files etc.

Carsten

> Giacomo Pati wrote:
> 
> On Thu, 28 Jun 2001, Carsten Ziegeler wrote:
> 
> > Hi Team,
> >
> > first the good news: We have a working cocoon: protocol. Just add
> >
> > <map:match pattern="test">
> > 	<map:generate src="cocoon://hello.html"/>
> > 	<map:serialize type="xml"/>
> > </map:match>
> >
> 
> Awesome work! Congratulation.
> 
> > to your sitemap and you will get the response of the hello.html
> > pipeline as xml.
> >
> > The ContentAggregator now uses these cocoon: urls, too.
> >
> > Let's start the problems now:
> > - We need to define the exact meaning of the cocoon: url, is it
> > relative to the current sitemap or does it always start at the
> > root sitemap?
> >
> > - The ContentAggregator was designed to aggregate pipelines. We
> >   could now use it to aggregate any xml sources! But this would
> >   require to explicitly use the cocoon: protocol in the <map:part>
> >   of the aggregation (breaking compatibility).
> >   I vote +1 for this change.
> 
> +1
> 
> > - And now the really bad news:
> >   The cocoon: protocol does not use the URLFactory nor does it
> >   use any URL object. Why? Well, last year was the discussion
> >   about adding own protocol handlers in a servlet environment
> >   in this mailing list. The conclusion was, that the usual
> >   java approach is not possible.
> >   So I thought of making a fake URL object. But this is neither
> >   possible as the URL class is final.
> >   The current solution: The URL objects and the cocoon: protocol
> >   are wrapped by the Source object (introduced month ago with
> >   the SourceResolver). There is the URLSource object which wrapps
> >   URLs and the SitemapSource object describing a pipeline.
> >
> >   This approach together with the fact that adding real protocol
> >   handlers in a servlet environment is not possible leads me
> >   to the conclusion that the URLFactory is not of as much use
> >   as it could be.
> >   I would suggest to move it over to a SourceFactory which produces
> >   Source objects from an url.
> 
> I have no problems with this.
> 
> >
> > PS: Oh, I forgot to mention that of course the cocoon: protocol
> >     is directly streamed into the pipeline, this means retrieving
> >     the content of this url is not done by first converting
> >     the sax events into a byte stream and then reparsing this
> >     to create sax events.
> >     The Source object is now capable of streaming its content.
> >     I changed the FileGenerator to use this feature directly. We
> >     should update the other components as well.
> 
> Real cool :)
> 
> Giacomo
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org