cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinhard_po...@gmx.net>
Subject [Vote] Cocoon Advanced Control Flow
Date Wed, 09 Jul 2003 12:37:00 GMT

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!


Mime
View raw message