Hoping I'm not too late. Please interpret this not as personal attack or something else. I like the idea of the flow, but the javascript implementation inhibit me to take a deeper look into it.
> +------------------------------------------------------------------+ > | 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> -1, because it leaves the impression that the flow must be a script. Alternative, I would prefer <map:flows language="[yourLanguage]"> <map:flow src="script_1"/> <map:flow src="script_2"/> <map:flow src="script_..."/> <map:flow src="script_n"/> </map:flows> Just like generators and generator > [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> Again -1, functions are one way to implement a flow, see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105732879827785&w=2 Perhaps <map:start continuation="[yourFunction]"> > > [C] If a script provides continuations to continue > they are called within the sitemap using: > > <map:call continuation="[continuation-id]"/> <map:continue id="[continuation-id]"/> is for my opinion a better solution. > > [D] All flow interpreters[3] are Avalon components and declared > in the cocoon.xonf: > > <flow-interpreters default="[yourLanguage]" logger="[yourLogger]"> > ... > </flow-interpreters> +1 > [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) -1, I think our users are adult enough to decide, what they should use and what not. To get the full access to request/response/session and cm etc. seems to be harmless for me. > [F] FOM contains following objects: > > * cocoon > * request > * response > * session > * cookie > * log > * context > * continuation +0 > [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". -0 > +------------------------------------------------------------------+ > | 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] It just one solution. I don't like javascript, and the impression that all can be handle harmless in one Javascript function is dangerous, see handling transaction(hilbernate). I would love to see an alternative implementation. In my POV the flow belongs to the core, but not the javascript implementation. > [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> +1 > [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). +1 > [K] Behaviour of variables within the flow: > All variables within the flow scripts are shared by reference > over continuations. +1 > [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> +1 > [M] Getting and releasing of components has to be done explicitly > by the flow script programmer using:[7] > > cocoon.getComponent( id ); > cocoon.releaseComponent( component ); +1 Stephan.
