Jeremy Quinn wrote:
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
<snip/>
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 framework)
- 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.
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
