Daz: Some things I agree with, some things I don't - read on ....
Darrell DeBoer wrote:
On Tue, 10 Dec 2002 08:50, Leo Sutic wrote:I don't see the issue here.
However, there is concensus that a component should be able to specify anySlow 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.
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;
}
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;
}
From a technical perspective - casting the supplied context is no different from casting a context derived from a get. If you look at the first example, its simply a context object that is narrowed to a particular context domain. In the second example, there is not reason not to consider this a root context domain that is being used to access a set of different context domains.
From feedback I've been seeing, the main source of conflict arrises due to the interest of developers to narrow to convinience interfaces, but in doing so are locked into container specific solutions. As things stand there are two approaches to dealing with that - a small set of standard context interfaces at the framework level, and secondly, and architecture for portable context delivery. Both approaches allow for the convinience interface narrowing without lock-in at either root or derived scopes.
Providing the specilized context object observes the Context contract (i.e. does not force narrowing because all functionality is available via keyed objects) then the narrowing question becomes academic - or at least something that can be the decision of the dveloper.
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."
As things stand today - this is good advice.
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,
Understood.
where the "what does a context mean? what (if anything) gets provided in the context?" discussion still needs to take place.My definition (which has been shifting around a lot lately) is that context is an object that provides access to a set of keyed objects under a contextualization stage in a component lifecycle. The values of context objects may be modified by a container during the lifetime of a component as a result of applying a new context as a result of recontextualization. Context and the objects it exposes are distinct with respect to a ServiceManager and the objects a manager exposes due to the distinction in the stages when modification can occur.
I also think that the notions or recontextualization and reservicing (recomposition) are terribly badly documented and are central to the questions of distinctions between objects that we consider as data and objects we consider as services. I also think that the notions of data versus service are not notions that can or should be expressed though interfaces, but are instead more akin to programming practice.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
