Christopher Oliver wrote:
Vadim Gritsenko wrote:
Here you will have to explain to me why: Why whould you want to pass *only* this "bean"?
Because that is the "contract" between the flowscript and the presentation layer.
In Cocoon apps, presentation layer is usually XSL (and CSS) stylesheets. XSP pages or velocity templates should be used as data generation layer. In addition to these, there are ways to generate data out of XML:DB, CVS, simple XML files, directories, and remote sources; and ways to generate data using Transformers (not everybody likes XSPs), whole bunch of them.
What I refered to as the "presentation layer" includes generators as well.
Because when using the flow you maintain the application state in JavaScript program variables.
And javascript program variables can be stored as object in session:
WebContinuation w = session.getAttribute("org.apache.cocoon.flow.WebContinuation");
Yes, that's true but the flowscript author doesn't need to know about or explicitly manage the session. He just calls
cocoon.createSession();
and stores data in javascript variables.
Essentially same is done for session-fw and xscript.
And also, how you will access session-fw data if you won't pass session object? Same for xscript data and request/session/context objects?
Not sure what you mean here. Can you explain?
There is session-fw, originally part of the Cocoon Portal; if you want to use flow with portal you better have access to this session objects in "flow presentation layer". XScript is a logicsheet which is somewhat similar to session-fw, but with access to data from XSP, not from Transformers. Recenlty addition has been proposed to allow access to the session-fw from the XSPs too (session-fw logicsheet).
I did find this in the archives:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103149427903698&w=2
The author was having problems using flow with the Portal. I don't fully understand the problem he experienced though.
Regards,
Chris
