You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2001/06/28 14:56:10 UTC
Re: AW: cvs commit: xml-cocoon2/src/org/apache/cocoon/transformation
I18nTransformer.java TraxTransformer.java
Carsten Ziegeler a écrit :
>
> 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>
>
> to your sitemap and you will get the response of the hello.html
> pipeline as xml.
>
> The ContentAggregator now uses these cocoon: urls, too.
>
Great job, Carsten !
> 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?
>
Since "cocoon:" isn't a real URL protocol (host and port have no meaning
here), it could depend on the number of "/" characters, i.e. :
- "cocoon:hello.html" : relative to the current URI
- "cocoon:/hello.html" : relative to the current sitemap
- "cocoon://hello.html" : absolute from 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 also. This increases consistency since all "src" attributes will have
the same behaviour (filesystem access when no protocol is specified).
> - 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.
>
> 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.
>
> Carsten
>
+1 for having SourceFactory being cocoon's preferred way to retrieve
content. This allows to have particular schemes like cocoon: while still
being able to use regular URLs.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org