Re: [PROPOSAL] Pipeline Level Flow Extension

[Ovidiu Predescu]

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 <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs ...)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]