Re: Flow wishlist :)

[Ovidiu Predescu]

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:

JSLog.java
- provides object 'Log' to the script
- provides functions:
Log.debug(string)
Log.info(string)
Log.warn(string)
Log.error(string)

JSCocoon.java
- 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)

JSWebContinuation.java
- provides the object 'WebContinuation'
- provides the object variables:
WebContinuation.id
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.

Regards,
Ovidiu

--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]