Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:Sylvain Wallez wrote:The discussions around Stefano's "Cocoon blocks version 1.1" showed the need for pipelines to provide not only resources, but also services, identified by their URI.
This document defines this concept of "pipeline service", which, as we will see, consists in using pipelines as sitemap components (generator, transformer and serializer). It is separated from the blocks design document since pipeline services can be used without blocks, even if they will be mostly useful in that context.
Thanks for writing this Sylvain, it's very helpful.
[snip]
In short, what you are describing is a model for pipeline extension: one pipeline 'extends' another pipeline by calling it and cocoon transparently adapts it by removing the parts which aren't useful.
I do see the problem of cocoon transparently removing pipeline components, but it feels more like OOP inheritance where the system transparently ignores the overloaded method.
Yes, the parallell is a little streched, but I think that the fact that nobody ever complained about the fact that serializers are ignored on cocoon: subpipeline calls makes me think that the concept is not so unfriendly.
Moreover, the fact of allowing *complete* pipelines is also tremendously helpful for debugging purposes and for block-reuse: instead of having passive pipeline fragments, we'll have the ability to write a pipeline, test it and then extend it with another.
Note that a pipeline might still be required to be called directly.
I see two issues to be resolved before Sylvain's proposal can be implemented.
First one is naming issue. It's very confusing (to me, and I bet to users too) when ProcessingPipeline object built by sitemap engine after sitemap execution is referenced in the sitemap simply as "pipeline" - it can be very easiliy mistaken for map:pipeline section (the whole different beast). Thus, I suggest we use "cocoon" type instead of "pipeline" type. The reason is: because this name is more similar to "cocoon" protocol which does very similar thing: it lets you access ProcessingPipeline object, augment it, and use it.
Yep. I now use "cocoon" as you suggested in an earlier post.
Second issue is that clear understanding of how this new components relate to existing sitemap constructs such as views and resources. Its mainly documentation issue I think. On the surface, "pipeline as serializer" can be mistaken with a view, and "pipeline as transformer" is somewhat similar to broken resources implementation in 2.1.
Resources are internal only to a sitemap, so this proposal doesn't affect the way they're handled. BTW what's broken about resources in 2.1 ?
As for views, we already have defined how view relate to the "cocoon:" protocol. So I would use the same behaviour, which uses the well-known "cocoon-view" request parameter.
<snip/>
Can we do not use "pipeline" word for these components? That's the major concern I have.
As I said previously, I now use the "cocoon" word, which is best suited, as you suggested.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
