On Tue, 10 Dec 2002 08:50, Leo Sutic wrote:
> However, there is concensus that a component should be able to specify any
> interface that it should be able to cast the context to. That is, for every
> interface T,
>
> public void contextualize (Context context) {
> T myContext = (T) context;
> }
Slow down. I think it's very apparent from the discussions that there is
indeed *NO* consensus on this at all. That is, unless you completely ignore
the opinions of non-committers like Noel and myself on this.
This is IMHO, a very bad idea. Much better is this:
public void contextualize( Context context ) {
T myContext = (T) context.get( "container:context:T" );
}
So, a Phoenix BlockContext could be accessed as:
pulbic void contextualize( Context context ) {
String key = "phoenix:" + BlockContext.getClass().getName();
Object obj = context.get( key );
BlockContext blockContext = (BlockContext) obj;
}
Now, nothing stops Phoenix from having a BlockContext implementation that just
does:
return this;
when asked for that key. And nothing *prevents* a component from directly
casting, except that the component is then <i>tightly tied to Phoenix</i>
because this is <i>not defined in the Framework</i> contracts.
Other containers might want to provide a BlockContext, without having to tie
their *implementation* of Context to the interface, and implement the
BlockContext in a better way than IS-A. (Reusing the Phoenix implementation
fo BlockContext, but having their own Context implementation, for example. ).
So, in framework, we include in the contract definition:
"You should *never* cast the context to another interface, unless you want to
tie yourself to a single container. If a context interface is available by
casting, it will *always* also be available through a named key, defined and
documented by the container."
This way, Phoenix clients continue to work, but we don't have to use it as a
model for the way context should work.
This is Avalon4 contract tightening, I'm talking about, not Avalon5, where the
"what does a context mean? what (if anything) gets provided in the context?"
discussion still needs to take place.
--
cheers,
Darrell DeBoer
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
