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.
All of these data sources are configured through the sitemap, and have access to request/response/context/parameters objects. And they do not have access to the bean, AFAIK. With the exception of couple of places you mentioned in other email - like jpath logicsheet (why it is named like this? shouldn't it be flow logicsheet?)
And I still have question why don't you put this bean into request attributes? And why have such bean in the first place, why not just use request/session/application attributes?
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");
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).
And last one, why VelocityGenerator must be the only one ... hm ... crippled by the absence of request/session/etc?
That's not the case. All are equally crippled ;) For example, when using Xsp, the idea is that the only logic sheet you will ever use is the jpath logic sheet. This does not give you direct access to session, request, or context but only to the bean object. Likewise with XMLForm, you only have access to the bean itself.
HUH? /me extremely puzzled
Anyway, as you said, the limitation on XSP is only recommendation, not enforcement. Why VelocityGenerator can't follow the suit? Current state of affairs is anything but uniformity.
Vadim
