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 Sun, 16 Mar 2003 20:59:54 GMT
Stefano Mazzocchi wrote:

> Christopher Oliver wrote:
>> Here's a summary of some of the recent issues with the Flow for 
>> discussion:
>> 1) Storing the flow context object and continuation in environment 
>> attributes:
>> This seems easy to fix. But I personally don't understand the 
>> "objectModel". Can someone explain how to properly use it? But I 
>> think there is a more fundamental design question here: namely, how 
>> should the flow script communicate with generators, transformers, etc?

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().

> This is a very good question and I'm not sure I have an answer.
> Sylvain, what do you think? 

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 ?

>> 2) Concerns with exposing the componentManager:
>> I personally do not know what the proper solution here is. Can 
>> someone explain the proper use of component managers and make a 
>> suggestion on how to solve this?
> I think that a way to solve this would be to have a direct FOM hook to 
> the cocoon component manager... but this should not allow people to 
> have access to sitemap components, only to those components defined in 
> roles.
> But I'm thinking out loud here. 

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.
- the Redirector, currently available to actions (I consider redirecting 
as a particular case of a view).

The FOM also provides some methods not related to any of the above 
objects such as sendPage().

>> 3) Duplication of functionality between VelocityGenerator and 
>> FlowVelocityGenerator:
>> This is clearly bad, I agree. I think these could be merged back 
>> together - the old behavior would apply if the flow context object 
>> isn't available. But this probably depends somewhat on the answer to 
>> (1).
> Ok, so you are stating that once we solve 1) we solve 3) as well? 

Could be ;-) If flow data goes through the object model, publishing the 
object model to the Velocity engine could solve the problem.

>> 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?
>> I also noticed that it isn't fun to debug Velocity templates. If the 
>> generated xml has errors, the XML parser reports the line number of 
>> the generated xml document, which isn't preserved anywhere. In that 
>> case it would be nice if the Velocity generator saved the generated 
>> xml document somewhere, or at least logged it.
> I think it makes sense.
> I also noted a few things looking at the FOM thru the IDL 
> documentation: there is a lot of duplication between the Global and 
> Cocoon objects and I would like to sort it out.
>                                     - o -
> 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.
> 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).
> So, no methods come out of the blue.
> what do you think?

I share your "attach-a-method-to-an-object" concern, which certainly 
comes from our heavy Java background.

This is mainly a naming and classification problem : how do we organize 
these objects available to the JS script ? Should all the FOM be defined 
as global variables, or available as properties of some "classifier" 
objects, e.g. "cocoon.request", "cocoon.sendPage()", "avalon.logger", 
"avalon.manager" ? I personnaly would go for the second choice.


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

View raw message