cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [PROPOSAL] Pipeline Level Flow Extension
Date Wed, 30 Oct 2002 03:42:47 GMT

On Tuesday, Oct 29, 2002, at 01:51 US/Pacific, Michael Melhem wrote:

> On Mon, 28 Oct 2002, Ovidiu Predescu wrote:
>>
>> On Monday, Oct 28, 2002, at 07:25 US/Pacific, Michael Melhem wrote:
>>
>> I don't think there's a good reason for this complexity. Do you have a
>> good use case for such a usage?
>
> Im not sure whether this would constitute a "good" use case.  But
> in our application we have a particular reports sitemap which
> contains a pipeline for handling the report masks/forms and a
> pipeline for handling the actual reports. Something like the following:
>
> <map:pipeline id="report-mask">
>   ...
>   <map:match pattern *-mask.xml>
>   </map:match>
>   ...
> </map:pipeline>
>
> <map:pipeline id="report">
>   <map:match pattern report.xml>
>   </map:match>
>
>   <map:match pattern report2.xml>
>   </map:match>
> </map:pipeline>
>
> What I would like to be able to do is specify a flow for
> the report masks, and a seperate flow for the reports (with
> out having to have a seperate sitemap in this case). This seems
> to me "natural" thing one might wish to do, rather than "complex"
> thing. :)
>
>>
>> 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?
>
> Of course one could specify all the required flows(js functions) in
> one script, but for the purposes of readability, scalability, and SoC,
> I thought it might "nice"(although not essential) to have the option of
> being able to split up the flow within the sitemap.
>
> Since, as you know, cocoon sitemaps can already be broken up into 
> smaller
> conceptional sections called pipelines, I thought maybe we could have
> the option of splitting up flows at the same level.

You can still declare your two flows in two separate scripts, like this:

<map:flow>
   <map:script src="report-mask.js"/>
   <map:script src="report.js"/>
</map:flow>

Logically you separate them in two scripts, even though they will share 
the same scope for global variables and function names.

I don't think separating the global scope for the two flows would bring 
much value for this particular use case. One place where it does make 
sense to separate the interpreters is in different sub-sitemaps, which 
may belong to different deployments. This use case is supported today.

Also keep in mind that each separate global scope you create consumes 
memory. Separating these scopes at such granularity will only make 
applications multiply the memory occupied by such scopes.

>>
>>> 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.
>
> Yes, I might take a look at this, since now it looks like we are going
> to use "flow" in our app. :)

Sounds terrific! Please provide any feedback you might have on this 
functionality.

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


Mime
View raw message