cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Discussion of Flow Issues
Date Mon, 17 Mar 2003 22:43:55 GMT
Christopher Oliver wrote:

> 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? 

Nothing, you listed them all :-)

>> 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? 

Avalon-related objects are those that are made available to components 
by the Avalon framework through the various lifecycle interface. These 
are a Logger (LogEnabled interface), an Avalon context (Contextualizable 
interface), a ComponentManager (Composable interface) and a 
Configuration (Configurable interface), although this last one doesn't 
really makes sense for the flow.


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

Cool. Seems like we're rapidly converging towards a consensus :-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message