Return-Path: 
 <cocoon-dev-return-33185-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 87651 invoked by uid 500); 22 Nov 2002 19:29:15 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 87631 invoked from network); 22 Nov 2002 19:29:14 -0000
Message-ID: <3DDE858C.2020406@verizon.net>
Date: Fri, 22 Nov 2002 14:29:16 -0500
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Using pipeline as sitemap components (long)
References: <3DDCAFEA.5050900@anyware-tech.com> <3DDE7941.2050804@apache.org>
In-Reply-To: <3DDCAFEA.5050900@anyware-tech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at out004.verizon.net
 from [139.85.116.234] at Fri, 22 Nov 2002 13:29:17 -0600
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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.

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.


> For example:
>
>  <match pattern="*.xml">
>   <generate type="file" src="{1}.xml"/>
>   <serialize type="xml"/>
>  </match>


>  <match pattern="*.html">
>   <generate type="pipeline" src="{1}.xml"/>
>   <transform src="xml2html.xslt"/>
>   <serialize type="html"/>
>  </match>


As it was already mentioned (in previous mail), this is equivalent to 
combination of file generator with cocoon protocol. But, I do not see 
any issues adding special "cocoon" type generator:

<generate type="cocoon" src="{1}.xml"/>
<serialize type="xml"/>

And its implementation could differ a lot from file generator/cocoon 
source pair...


...

> The nice thing would the above is that if the generation of the *.xml 
> resource is changed, this is automatically inherited by all the 
> pipelines that build on it.
>
> Note that one might also want to connect to "views" of those 
> pipeline... so for example why don't we add the ability to specify 
> which "view" of the pipeline we should start from?
>
>  <map:generate type="pipeline" src="/whatever/resource" view="content"/>
>
> What do you think think?


Can we do not use "pipeline" word for these components? That's the major 
concern I have.

Vadim




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