cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: More on FOM
Date Mon, 30 Jun 2003 15:45:09 GMT
Ricardo Rocha wrote:

> Hi friends,
>
> The following items reflect the discussions Stefano and I have had 
> around the FOM:
>
> - The load(uri) global function should be supported. This is clearly 
> needed for nested source file inclusion (which <map:script> does not 
> support).
>
> - The cocoon.releaseComponent(component) method should be supported in 
> conjunction with cocoon.getComponent(id). Further discussion is needed 
> about whether the FOM implementation should automatically take care of 
> releasing components.


Hehe, I should go to Ecuador, as I advocated both ;-)

I suggested that components being heavyweight resource, allowing them to 
cross continuation boundaries should be prohibited. Automatic release 
doesn't seem a good solution to me, as it would mean that script 
variables would hold released components, thus leading to unpredictable 
behaviour (think about stateful pooled components). So my opinion is to 
raise an error if there are some unreleased components when a 
continuation is created. This will allow users to quickly learn the safe 
practices related to component management in flow scripts.

> - There should be unrestricted access to all components via 
> cocoon.getComponent(id).


Hehe again ;-)

> Among other goodies, this will give indirect access to Actions and 
> Modules without providing explicit FOM support for them. Access to 
> request input modules, in particular, should account for 
> request.getURI(). 


Two remarks here :
- if we give access to request.getURI through an input module, then why 
removing it from the request object ??

- modules need the object model and actions need it also, along with a 
(Cocoon) resolver and a redirector. How will the flow be able to access 
these objects to pass them to the components ?

IMO, the second point calls for some refactored interfaces since the 
(Excalibur) resolver is now a regular component and we decided some time 
ago to make the object model accessible through the Avalon context 
(don't know if it has been implemented, though).

> - Access to continuation objects should be provided.
>     var kont = sendPageAndWait(uri, data)
> This is deemed necessary as certain continuation usage patterns may 
> call for explicit, programmatic invalidation of continuations.
>     - Properties
>         - id
>     - Methods
>         - getParent()
>         - getChildren()
>         - invalidate()
>     - Events
>         - onExpiration()


Sounds good.

> What do you guys think? 


Read inline !
Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message