Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Mon, 28 Oct 2002 21:18:34 -0800
Subject: Re: [PROPOSAL] Pipeline Level Flow Extension
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: 
 <Pine.LNX.4.43.0210281503140.19535-100000@fztig938.bank.dresdner.net>
Message-Id: <DF5E4E68-EAFD-11D6-BDA1-00039398D61E@cup.hp.com>

Hi Michael,

On Monday, Oct 28, 2002, at 07:25 US/Pacific, Michael Melhem wrote:

> Hello Cocooners,
>
> I have a proposal for "pipeline level flowmaps" (and flowmap chaining)
> as an extention to the existing sitemap-level flowmaps.
>
> This proposal is based on the assumption that at the moment, each
> sitemap can define *at most one* flow controller as follows:
>
> <map:flow language="JavaScript">
>   <map:script src="calc.js"/>
> </map:flow>
>
> If you consider that within each sitemap its *already* permissible to
> utilize several different pipelines (including different pipeline
> implementations).  Then it might make sense to allow the user the
> option of setting flow controllers on a per pipeline basis as well.
>
> This idea can be extended to include something like
> 'pipeline flowmap chaining': where if the function/continuation
> is not available at the pipeline-level,
> then flow control is deferred to the sitemap.
>
> To illustrate, here is what a sitemap.xmap
> using pipeline-level flow could look like:
>
> <!-- Define available flows for this sitemap  -->
> <map:flow language="JavaScript">
>   <!-- Note: a "default" sitemap flow is not mandatory -->
>   <map:script src="default.js" name="default-flow" default="true"/>
>   <map:script src="specific.js" name="specific-flow"/>
> </map:flow>
>
> <map:pipelines>
>
>   <!-- this pipeline would use the default flow -->
>   <map:pipeline>
>   <map:match pattern="Kont/*">
>     <map:call continuation="{1}"/>
>   </map:match>
>
>   <map:match pattern="login/">
>     <map:call function="login"/>
>   </map:match>
>   </map:pipeline>
>
>  <!--
>      this pipeline would use the specific flow
>      which might override some of the behavior
>      of the default flow
>   -->
>   <map:pipeline flow="specific-flow">
>     <map:match pattern="myKont/*">
>       <map:call continuation="{1}"/>
>     </map:match>
>
>     <map:match pattern="mylogin/">
>       <map:call function="mylogin"/>
>     </map:match>
>   </map:pipeline>
>
> </map:pipelines>
>
> What does the mailing list think?

I don't think there's a good reason for this complexity. Do you have a 
good use case for such a usage?

Since the scripts and the functions defined within are visible at the 
sitemap level, why not simply directly call the specialized functions 
from the second pipeline? Do you really need the two scripts to not 
share anything between them?

> If no one sees any problems with the above, then I would be
> happy to volunteer to implement this.

If you really want to spend some time on the flow layer, I would rather 
like you spend some time working on some of the items in the TODO file 
in src/java/org/apache/cocoon/components/flow/. The thread to expire 
continuations would be a very good first task.

Best regards,
-- 
Ovidiu Predescu <ovidiu@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, 
Emacs ...)


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