cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [VOTE] Unrestricting the FOM
Date Tue, 15 Jun 2004 09:57:45 GMT
Jeremy Quinn wrote:

> On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:


>> Looking at the vote results, the general opinion is to remove the API 
>> restrictions (got only +1's),
> Good
>> but not tie the FOM to a particular Avalon object (got lots of +0's 
>> and a -1).
> This is more difficult to understand, but I could see why some were 
> worried.
>> So let's drop this cocoon.avalonContext proposal. Firstly because it 
>> becomes less useful if the FOM is unrestricted, and secondly because 
>> we can easily add the ContextAccess I proposed to Jeremy as a utility 
>> class. People using that class will know by doing so that their app 
>> becomes tied to Avalon.
> That is fine by me.
> Shall I commit the sample class you provided?
> Do you have any preferences for where it should live?
> Or do you have a more sophisticated way of adding this functionality, 
> that you would prefer to use instead?

I see two possible locations for this code:
- in a new o.a.c.components.flow.util.AvalonContextAccessor class (note 
the explicit mention to Avalon to clearly show the dependency on the 
- in o.a.c.components.ContextHelper, which alread holds a number of 
context-related methods.

The second solution has the benefit of concentrating all Context-related 
features in a single class and so has my preference.



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

View raw message