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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
