cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: [Vote] Cocoon Advanced Control Flow
Date Mon, 14 Jul 2003 10:10:04 GMT

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.


Mime
View raw message