Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3F00682A.10801@apache.org>
Date: Mon, 30 Jun 2003 11:41:14 -0500
From: Ricardo Rocha <ricardo@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030529
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: More on FOM
References: <3F004DC5.6020407@apache.org> <3F005B05.1010002@anyware-tech.com>
In-Reply-To: <3F005B05.1010002@anyware-tech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

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

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

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

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

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

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


Ricardo