cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow Issues
Date Mon, 17 Mar 2003 03:57:43 GMT
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.

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 = 

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. 

/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.


View raw message