avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] New Lookup mechanism
Date Wed, 14 Apr 2004 07:40:28 GMT
Stephen McConnell wrote:
> 
> Hi Marcus!
> 
> I've got some general questions about selection that perhaps 
> you or other could fill me in on.  First off - I'm separating 
> out in my head three different things:
> 
>     1. the interface we use for locating something (lets call
>        it Locator for the purpose of discussion)
>     2. the interface used to supply and instance of a Locator
>        to a component
>     3. the sort of information that a component can include
>        in a locate request and the expected behavior of
>        container in resolving such a request
> 
> Item (3) is the thing that IMO needs to be expanded on. 
Yes.

> Here 
> is a couple of examples of an invocation followed by a couple 
> of questions. 
> Please not that I'm also not really worried about the 
> argument or signatures just yet - so don't pay any attention 
> to the approach - I'm in information gathering stage!
> 
>    public void someDeliveryMethod( Locator locator )
>    {
>         Map map = new Hashtable();
>         map.put( "color", "red" );
>         Football football = locator.locate( Football.class, map );
>    }
> 
> In the above the component implementation has to assume that 
> a container has been configured such that "color" is 
> understood - i.e. is translatable to something that will help 
> in the determination of the appropriate instance to be returned.
> 
> Possible interpretations:
> 
>    1. color is an attribute of a component type
>    2. colour is an attribute of a service implemented by a
>       a component type
>    3. color is a feature attributed to a component model
>       (i.e. component model x has configuration y and is
>       tagged with attribute color=red)
>    4. color is an attribute used by a selection handler
>       that knows about the Football class
> 
> Some questions:
> 
>    1. if color is understood by a container, but no solution
>       are resolvable - is that a failure or is the container
>       obliged to return at least some football
> 
>    2. which leads to the question .. should we be describing
>       a Query object instead of a map? E.g.
> 
>         Constraint color = new Constraint( "color" );
>         color.setRequired();
>         color.setValue( "red" );
>         locator.locate( Football.class, new Query[]{ color } );
> 
Regardless of what we include as the information in the call to
locate, it should be as simply as possible. This information
is "evaluated" by the container and therefore it has to be
"configured" so the container can deliver the correct component.

In most cases, this extra information is not needed: this happens
when you have exactly one implementation for a service, so you
have one-to-one relationship. 
However, the information is required as soon as you have a 
one-to-many relationship. In this case, you the client might
want to exactly specify which implementation it want to use.
So, I think it's sufficient to give each implementation a key
for the container and the client uses this key when calling
the locate method. This key should be a simple string,
so the above could read:
locator.locate(Football.class, "red");

In my eyes this is simple but sufficient.

WDYT?

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message