Digging into the archives I found Stefanos "RTs from linkmaps to
flowmaps"
from 2001-03-05.[1] He wrote "Take a piece of paper, avoid thinking you
are writing an application for the web, so avoid taking into
consideration
technical constraints (like the request/response paradigm, intrinsic
statelessness, low bandwidth, proxying, etc..) and draw a diagram of the
latest application you wrote. What you should outline, at this stage,
is the 'skeleton' of the flow: this should be drawn to give the other
people
in the team the overlall picture of what the application is doing."
Finally after more than 2 years of a lot of work (here again many thanks
to
Ovidiu and Christopher and all the others for their real great efforts)
Stefano's vision became reality and we are ready to vote on the
"Cocoon Advanced Control Flow" and its first implementation based on a
"continuations aware JavaScript" interpreter:
+------------------------------------------------------------------+
| Cocoon Advanced Control Flow (in general) |
+------------------------------------------------------------------+
[A] The "Cocoon Advanced Control Flow" provides a controller that is
linked into the sitemap (as child element of <map:sitemap .../>:
<map:flow language="[yourLanguage]">
<map:script src="script_1"/>
<map:script src="script_2"/>
<map:script src="script_..."/>
<map:script src="script_n"/>
</map:flow>
This reflects that the flow is not a *usual* sitemap resource but
something else.
In order to read the scripts the SourceResolver is used.
[B] Functions provided by scripts can be called within the sitemap
using:
<map:call function="[yourFunction]">
<map:parameter name="x" value="y"/>[2]
</map:call>
There are no special restrictions where you can put
it within <map:pipeline .../> (e.g. put it within action elements)
[C] If a script provides continuations to continue
they are called within the sitemap using:
<map:call continuation="[continuation-id]"/>
Again, there are no restrictions where you can
put it within the sitemap (<map:pipeline .../>)
[D] All flow interpreters[3] are Avalon components and declared
in the cocoon.xonf:
<flow-interpreters default="[yourLanguage]" logger="[yourLogger]">
...
</flow-interpreters>
[E] All interpreters have to implement the Flow Object Model [FOM][4]
as far as possible but *must not* extend it without prior vote.
They also have to support all "FOM-aware" components (e.g.
JXTemplateGenerator/Transformer)
[F] FOM contains following objects:
* cocoon
* request
* response
* session
* cookie
* log
* context
* continuation
Find details on the properties and methods here[4].
[G] The FOM does not grant access to actions and input modules
but the flow interpreter *can* provide support for it but must not
give them the appearence of "first-class-Cocoon-citizens".
+------------------------------------------------------------------+
| JavaScript Interpreter |
+------------------------------------------------------------------+
[H] Our first and currently only[5] interpreter implementation is
a Javascript implementation based on Mozilla Rhino which
has been extended to support continuations.[6]
This JavaScript interpreter completly supports FOM
and provides legacy support for actions and input modules by
loading a "leagacy.js" script. (to be implemented)
[I] This JavaScript implementation is declared in the cocoon.xconf:
<flow-interpreters default="JavaScript" logger="flow">
<component-instance name="JavaScript"
class="org.apache.cocoon.components.flow.javascript.
fom.FOM_JavaScriptInterpreter">
<load-on-startup>resource://org/apache/cocoon/components/
flow/javascript/fom/fom_system.js</load-on-startup>
<reload-scripts>true</reload-scripts>
<check-time>4000</check-time>
<!--<debugger>enabled</debugger> -->
</component-instance>
</flow-interpreters>
[J] Flows and sessions:
(i) A flow script does not create a session automatically.
Accessing the session object (is a property of the cocoon
object) leads to the creation of a session if no session
is available.
(ii) The global scope of a flow only lives as long as the session
which the flow is tied to is active.
So if the session expires or you use another client to
continue a 'waiting' function you only have access to the
local scope within the flow function.
(iii) All scripts within a <map:script>...></> part share the
same global context. If you want to share more objects
you need another scope (request, session, context).
[K] Behaviour of variables within the flow:
All variables within the flow scripts are shared by reference
over continuations.
[L] A continuations manager based on the excalibur-event packages
is responsible for the expiration of continuations. It is
declared in the cocoon.xconf:
<continuations-manager logger="flow" time-to-live="3600000">
<expirations-check type="periodic">
<offset>[timeInMs]</offset>
<period>[timeInMs]</period>
</expirations-check>
</continuations-manager>
[M] Getting and releasing of components has to be done explicitly
by the flow script programmer using:[7]
cocoon.getComponent( id );
cocoon.releaseComponent( component );
I know it's a lot ;-) but I don't want a general vote on such an
important part as the "Cocoon Advanced Control Flow" (many of us
consider it as an equal part to sitemaps).
Thank you for voting/reading so far (13 items ;-)!
Cheers,
Reinhard
o-----------------------------------------------------------------------
--o
[1] "RTs from linkmaps to flowmaps" by Stefano Mazzocchi
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98379467820862&w=2
[2] Jeremy's issue of sorting of the parameters is added to the
todo list. {http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow]
[3] I'm aware of Sylvain's and Marc's proposal on changing
the scope of available controllers. I contacted Sylvain off-list
and the said that they want to come up with a concrete
implementation
of their proposal in the future and this should *not* influence
the release of Cocoon 2.1 as the proposed changes would only have
a small impact on the *public* interfaces.
[4] FOM at Cocoon Wiki! [http://wiki.cocoondev.org/Wiki.jsp?page=FOM]
[5] Our more exactly "only interpreter which is included into Cocoon".
Another implementation (using the commercial ATCT) is described
here: [http://www.freeroller.net/page/alexkrut/20030514] by
Alex Krut
[6] [http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/
rhino1_5R4pre/?cvsroot=rhino]
[7] It is planned to raise a JavaScript exception if a component is not
released before sendPageAndWait is called but not implemented yet!
