cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Using pipeline as sitemap components (long)
Date Fri, 22 Nov 2002 10:49:37 GMT
Thanks Sylvain for this RT on a missing piece for the blocks concept.
More inline:

Sylvain Wallez wrote:
> 
> <snip/>
> 
> 
> Pipelines as generators
> -----------------------
> 
> This leads to a first conclusion : using a pipeline as a generator means 
> using the SAX events produced by the last XMLProducer of that pipeline, 
> i.e. the last transformer or the generator if there are no transformers.
> 
This is only the technical implementations because of performance. The
first implementation of the cocoon: protocol actually required the xml
serializer as the result was serialized and then parsed again - for
performance reason we made it possible to use the SAX stream directly
from the last XMLProducer.
In fact, that the serializer does not have to be the xml serializer
can be considered as a bug or weakness.

> Since we've used a pipeline as a genererator, let's introduce a new 
> generator for this purpose, instead of using the "file" one, which fools 
> us in thinking we use a full pipeline when it actually strips out the 
> serializer :
> 
>   <map:match src="first-uri">
>     <map:generate type="pipeline" src="/other-uri"/>
>     <map:transform src="foo.xslt"/>
>     <map:serialize/>
>   </map:match/>
> 
> I don't see a need for a new sitemap element such as "map:call-pipeline" 
> or "map:generate-from-pipeline". What we want is to generate and initial 
> content in the current pipeline, and for this we just use a particular 
> implementation of a generator, as we already do for files, XSP, etc.
> 
I don't see the need for this special generator as the current components
(file generator - which has not the best name) do it already. Another
component would imho more confuse than help. And what do you want to do
with map:aggregate?

> 
> Pipelines as serializers
> ------------------------
> 
> <snip/>
> 
> How do we use this ? Well, just as for the generator, let's define a new 
> "pipeline" serializer :
> 
>   <map:generate src="another_xdoc.xml"/>
>   <map:serialize type="pipeline" src="doc2pdf"/>
> 
> Note : the "src" attribute doesn't currently exist on <map:serialize>, 
> but it seems the more natural and consistent way to name the called 
> pipeline. Wether this translates to implementing SitemapModelComponent 
> or not is another story.
> 
Ok, I would call this "src" but something different, but that doesn't
play a role for the concept itself.
What I don't like is that a complete pipeline is called and there
the generator is ignored. This would confuse everyone, I guess.

> 
> Pipelines as transformers
> -------------------------
> 
> <snip/>
>
>    <map:match pattern="a_page">
>      <map:generate src="an_xdoc.xml"/>
>      <map:transform type="pipeline" src="xdoc2skinnedHtml"/>
>      <map:serialize type="html"/>
>    </map:match>
> 
> and
> 
>    <map:match pattern="xdoc2skinnedHtml">
>      <map:generate type="dont_care"/>
>      <map:transform type="i18n"/>
>      <map:transform type="xdoc2html.xsl"/>
>      <map:transform type="htmlskin.xsl"/>
>      <map:serialize type="dont_care"/>
>    </map:match>
> 
Again, this looks a little bit strange that generator and serializer
have to be specified but are actually ignored. I can already hear
thousands of complains from users telling: "Why do I have to declare
them when they are not used?".

I haven't thought much about this, but I think if we want to define
services which can be called, than we should have a special syntax for
this, to make explicitly clear that services are defined and not
pipelines.

I personally would like to add new concepts for new things rather 
than to try to press them into existing concepts where they do not
fit 100%.

It's a pitty that we didn't had time to discuss this face-to-face,
because that's a lot easier as I learned from the blocks concept...

Carsten


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


Mime
View raw message