cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: Discussion of Flow Issues
Date Mon, 17 Mar 2003 00:56:44 GMT
Sylvain Wallez wrote:
> A short explanation about the "object model". Cocoon abstracts its 
> runtime environment through the Environment interface. An Environment 
> object gives access to a number of things that are relevant to the 
> pipeline/sitemap engine only and should not be visible from other 
> components to avoid uncontrolled access to data managed by the 
> pipeline/sitemap engine. These include for example the response 
> outpoutstream, the current context prefix (changed by <map:mount>), etc.
> To provide those parts of the Environment that are safe to be used by 
> other components and required by them to do their job, the Environment 
> provides a so-called object model (Environment.getObjectModel()), which 
> is a Map of named objects, mainly Request and Response. This Map is 
> passed to every sitemap component during the call to setup().

What objects besides the Request, Response, Session and Context are in 
the "object model"? The flow script doesn't use the Response (and if you 
use XMLForm, it doesn't use the Request either). The Session isn't 
needed because when you use flow scripts you can store your application 
state in JavaScript progam variables instead of as session attributes. 
So what's left?

> What I suggested in the mail linked above is to use the object model, 
> already used as a communication means between the environment and other 
> components to communicate flow results. This suggestion comes both from 
> the fact that the object model is the "natural" way for the environment 
> to communicate public information to other components, and from the fact 
> that we can consider flow data as some additional data available in the 
> sitemap when called from a flow script.
> So we need two more values in the object model Map : one for the value 
> dictionary, and one for the continuation.
> How does it sound ?

That would work. But as above, now what other objects are in the object 
model and what are they used for?

> I'm not sure this "FOM" thing has been defined compared to the 
> Environment's object model. My POV is that the FOM is the set of objects 
> that are visible as global variables in a flow script.
> This must include :
> - the Environment's object model (but not the Environment itself),
> - Avalon-related objects that Java components (as opposed to JavaScript) 
> obtain through the Avalon lifecycle interfaces. These are the Logger, 
> the (Avalon) Context, and the ComponentManager. I don't know if there's 
> a need for a Configuration.

I don't understand this. Can you explain what "Avalon-related" objects are?

> - the Redirector, currently available to actions (I consider redirecting 
> as a particular case of a view).


>>> 4) JavaScript Database API has no business being in the flow
>>> We all agree on this. But we need someplace to put useful JavaScript 
>>> stuff - as part of optional "blocks" or something like that.
>> yes.
>>> In my own use of the flow, I've also noticed the following bugs:
>>>   - Script reloading is partially broken. Sometimes scripts don't 
>>> reload properly. This is normal when you are in a continuation - the 
>>> continuation contains a compiled copy of the script and doesn't see 
>>> the new reloaded one. But it happens occasionally even in top level 
>>> calls.
>>>   - With certain Exceptions the script file names and line numbers 
>>> are not reported
>>>   - Cocoon.load() doesn't work
 >> I saw some commits of yours on this, is cocoon.load() functional now?

In preparation for refactoring this stuff, I think I've now got script 
reloading and Cocoon.load() working.

>> The main objects in the FOM are:
>>  1) Global -> indicates methods that are available without object prefix
>>  2) Cocoon -> cocoon-related methods that are avalilable with the 
>> cocoon. object prefix
>> First of all, is there a reason to have both?
>> I find the concept of prefix-less method calls a little weird coming 
>> from the java world. they come out of the blue.
>> Also, there is a lot of duplication between the two since they provide 
>> the same methods. this is very bad, IMO.

They're not really "prefix-less".


is really the same as


where "this" identifies the top-level object.

But you're right, in my opinion, about the duplication. It makes no sense.

>> So, I would like to propose to remove Global or empty it and move 
>> everything over to the Cocoon object.
>> This means that instead of doing stuff like:
>>   sendPage(...)
>> I propose to do
>>   cocoon.sendPage()
>> which outlines the fact that it's not the flow that sends the page, 
>> but it's cocoon that does (control is given back to the sitemap before 
>> sending the page).

Agree. But for the second reason: I think sendPage() is really an 
operation of the "cocoon".

View raw message