cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Flow wishlist :)
Date Sat, 30 Nov 2002 19:07:48 GMT
Sorry for the delay, I'm slowly catching up on my email, after the last 
week gone and the Thanksgiving holiday here in US.

On Saturday, Nov 23, 2002, at 12:49 US/Pacific, Stefano Mazzocchi wrote:

> This is actually the major reason why DOM was created: to standardize 
> the set of objects that are available from a page script in a browser 
> environment.
> So while DHTML is HTML + EcmaScript + DOM, FlowScript is EcmaScript + 
> Cocoon Flow Object Model (FOM?).
> This FOM is described in package 
> org.apache.cocoon.components.flow.javascript and so far includes:
>    - provides object 'Log' to the script
>    - provides functions:
>        Log.debug(string)
>        Log.warn(string)
>        Log.error(string)
>    - provides the object 'Cocoon' to the script
>    - provides the object variables:
>        Cocoon.interpreter
>        Cocoon.environment
>        Cocoon.request
>        Cocoon.response
>        Cocoon.session
>        Cocoon.context
>        Cocoon.componentManager
>     - provides the object functions:
>        Cocoon.load(script)
>        Cocoon.forwardTo(uri)
>        Cocoon.createSession()
>        Cocoon.removeSession()
>        Cocoon.displayAllContinuations()
>        Cocoon.callAction(type,source,parameters)
>        Cocoon.inputModuleGetAttribute(type,attribute)
>        Cocoon.outputModuleSetAttribute(type,attribute,value)
>        Cocoon.outputModuleCommit(type)
>        Cocoon.outputModuleRollback(type)
>     - provides the object 'WebContinuation'
>     - provides the object variables:
>        WebContinuation.continuation
>     - provides the object functions:
>        WebContinuation.invalidate()
>        WebContinuation.display()
> and, of course, the call-with-continuation methods sendPage*() which 
> are added to the interpreting environment directly.

This is a great explanation of the object model behind the control flow 
layer in Cocoon, thanks for taking the time to analyze the code and 
producing this.

> [ovidiu, we must make a serious effort to document this stuff or 
> people will simply keeping on being scared of what the flowscript is. 
> Since you are the man around that, I'd love if you could start at 
> least filling the above skeleton with what is missing and what the 
> calls are supposed to provide.]

Yes, I know, I have this item on my plate for a long time. I'll try to 
find some time to write all these down, but time is really scarce these 
days. I'll try to provide a skeleton for the docs, but I'd really 
appreciate if other people can jump in and put these bits of 
information together.

>> If we could read the flowscript from an internal pipeline we
>> would be set.
>>  <map:flow language="JavaScript">
>>    <map:script src="cocoon://something/prefs.js"/>
>>  </map:flow>
> hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in my 
> head, but I have several great examples of where having that would 
> rock the planet.... but still, I'm afraid of people going back adding 
> programmatical logic to the sitemap....

I don't think we need this. The flow scripts is normal code, it should 
not be loaded depending on runtime behavior. If you wish to obtain a 
different behavior depending on the pipeline, a different function in 
the flow script could be invoked.


Ovidiu Predescu <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message