cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: More on FOM
Date Mon, 30 Jun 2003 20:29:55 GMT
Ricardo Rocha wrote:

> Sylvain Wallez wrote:
>> Ricardo Rocha wrote:
>>> 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 ;-)
> You're welcome anytime my friend! :-)

Cool ! This is one of the good things of Apache : world-wide friends, 
ready to welcome you for good time and geek talks :-)

>> 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.
> I see your point Sylvain. Your solution sounds somewhat draconian but 
> it's probably the only safe bet...
> The question then becomes: does anyone envision real-world scenarios 
> in which stateful components *are* needed across continuation boundaries?
> (if so, imo, it might imply curent Avalon component management isn't 
> safe for continuations)
> Or can we *always* formulate our flow so that we don't need to keep 
> component state across continuations? (for example, database 
> connections can be acquired/released as needed precisely because 
> they're pooled). 

Databases connections are a good use case. IMO, the sequential nature of 
a flow script will make people want to keep stateful components as the 
do in "standard code", as it is somewhat unnatural to release a 
connection just before a sendPageAndWait() and then look it up just after.

The modified Rhino intepreter has some extensions to exception 
management to allow clearing and restoring variables when a continuation 
is suspended/reactivated. This will be very useful in large scripts when 
a continuation is suspended several function call deeper than the 
location where the component is used.

> On a separate thread, if *all* acquired components *must* be released 
> prior to creating a continuation... wouldn't it make sense for the FOM 
> implementation to automagically release them??
> I know it may sound dangerous at first, but then again it would 
> relieve developers from that tedious, anti-scripting release idiom...

Once again, I agree that explicit release is very unnatural. But 
automagic release is good only if we can have some automagic restore. 
For this we can have getComponent() actually return a proxy to the real 
component, and have the proxy do a release/lookup when a continuation is 
suspended/reactivated. But as elegant this may seem, this won't work : 
stateful components have... a state, and a release/lookup cycle destroys 
this state.

So I don't see any other solution...

>>> - There should be unrestricted access to all components via 
>>> cocoon.getComponent(id).
>> Hehe again ;-)
> Hahaha! There's nothing quite like the flavor of victory, is there? ;-) 

Mmmh... it's not about victory in the "fight" meaning, where there's a 
winner and a looser. We all win in discussing our thoughts and taking 
good ideas where they come. This time these are mine and, well, this 
feels good ;-)

>>> 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 ??
> Until proven otherwise, I don't think getURI() is _needed_ by the 
> flow, so the request object shouldn't expose it.

Actually, I think that if the flow needs something from the URI, this 
information should be passed by the sitemap through <map:parameters> in 
the <map:call>. The sitemap is responsible for handling the URI space, 
including extracting information from it for other components.

> Imo, the flow renders actions (and modules outside the sitemap) 
> unnecessary, so we shouldn't encourage their continued use by 
> providing FOM-level support for them. The idea, in the long term, is 
> to stop using actions (and xsp's, for that matter) in favor of the flow.
> That said, *indirect* access to modules and actions would satisfy 
> short-term, transitional requests to allow reuse of such "legacy" 
> components from the flow (if only by popular demand :-)). 

Ok. So we allow some abuse to satify transition of legacy applications 
or code.

>> - 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 ?
> Yes, you're right. Reinhard also pointed this out.
>> 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).
> Yes, this solution is clean. If the object model is available "legacy" 
> actions would be accessible.
> What I'd oppose -in any case- is giving actions/modules first-class 
> status in the FOM... 

Yep. These are components, and as such can be used as any other 
component. Note however, that we can imagine a "legacy.js" utility 
script that would provide convenience functions to access actions and 
modules. But this doesn't give them first-class status.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message