cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Discussion of Flow Issues
Date Sat, 15 Mar 2003 16:31:19 GMT
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?

This is a very good question and I'm not sure I have an answer.

Sylvain, what do you think?

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

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

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


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


I propose to do


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?


View raw message