Sylvain Wallez wrote:
Vadim Gritsenko wrote:
...
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.
Actually, it was vice versa: that's was the first post, second I wrote later to show how your proposal could be misinterpreted ;-)
And may be to help clear up some misunderstanding.
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.
My only point here is that I feel lots of users will ask questions. Some kind of doco will be needed.
BTW what's broken about resources in 2.1 ?
:)
AFAIR, as of now, they do not enforce completeness of the pipeline. Officially, resource *must* be the complete pipeline, from generator to serializer. In practice, in 2.1, you can call resource and complete it later with transformer or two and serializer. I think, this practice shall be terminated (== bug fixed) when we implement <transform type="cocoon">.
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.
I mean here, that also some doco explaining what's <serialize type="cocoon"> is and what's the difference with view (view is also kinda serialize ;) is required.
<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.
We are on the same page now. With terms and understanding. Which is a good thing.
Vadim
Sylvain
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
