On Mon, 28 Oct 2002, Ovidiu Predescu wrote:
Hi Ovidiu,
> 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?
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.
>
> > 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. :)
Best Regards,
Michael Melhem
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
