On 15 Jun 2004, at 10:57, Sylvain Wallez wrote:
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)
I can understand this one
- in o.a.c.components.ContextHelper, which alread holds a number of context-related methods.
I am not quite sure how this functionality would get added to o.a.c.components.ContextHelper.
It currently has all static methods, which are passed an existing org.apache.avalon.framework.context.Context Object.
The second solution has the benefit of concentrating all Context-related features in a single class and so has my preference.
Are you suggesting that this class be made Contextualizable and be given a getContext() method ?
So to use it for getting a Context, you would call
cocoon.createObject (ContextHelper).getContext ()
on it?Thanks
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
