You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Melhem <mi...@fztig938.bank.dresdner.net> on 2002/10/28 16:25:17 UTC
[PROPOSAL] Pipeline Level Flow Extension
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?
If no one sees any problems with the above, then I would be
happy to volunteer to implement this.
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Pipeline Level Flow Extension
Posted by Torsten Curdt <tc...@dff.st>.
> 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. :)
I second that - it would feel natural. ...but having a "default" flow and
"overriding" sounds like FS.
> 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.
If we don't support to split up flows within a sitemap this might give the
user/developer the burden of creating sitemaps where he wouldn't usually
create one - just for SoC.
> 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.
hm... I don't really see the connection between pipeline and flow internally
but from a user's point of view this might be ok :-/
This reminds me a little on the term "mounting flowmaps" like it was used ages
ago - maybe a mounting should really be considered... so it could be mounted
within a matcher? since usually a flow is uri related?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Pipeline Level Flow Extension
Posted by Ovidiu Predescu <ov...@cup.hp.com>.
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 <ov...@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
Re: [PROPOSAL] Pipeline Level Flow Extension
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
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 <ov...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Pipeline Level Flow Extension
Posted by Ovidiu Predescu <ov...@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 <ov...@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