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 requestItem (3) is the thing that IMO needs to be expanded on. 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 classSome 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 } );Any thoughts?
Cheers, Stephen.
Marcus Crafter wrote:
On Mon, 2004-04-12 at 16:35, Carsten Ziegeler wrote:
Niclas Hedhman wrote:
On Saturday 10 April 2004 00:24, Stephen McConnell wrote:
Secondly - concerning dynamic lookup I think we should be following something closer to the approach suggested by Bruno Dumon - ie.:
/** * @avalon.dependency type="Locator" key="locator" */ public void service( ServiceManager manager ) { // get the ref widget Locator locator = (Locator) manager.lookup( "locator" ); Widget redWidget = locator.locate( Widget.class, m_map ); }
The approach above is imho not better than the current Selector approach; it's slightly different so. I think you and Stephen are mixing the use of the lookup mechanism in Merlin and the interface/functionality provided by the framework. The framework api does not/should not know anything about meta info etc.
But it seems noone else apart from me is interested in enhancing the framework api, so we can skip this for now.
I'm actually interested in enhancing this mate. A while back I asked about the use of Class in lookup rather than a String Role:
http://marc.theaimsgroup.com/?l=avalon-dev&m=105914629325097&w=2
and there were various responses (rightly) pointing out the decisions behind it. I still tend to favour specifying the component you want by an interface Class instance, but I follow the reasoning behind using a String.
With service selector, I sent in an RT a while back about parameterized lookups which from what I can tell is similar (at a usage level) to the 'locator' above:
http://marc.theaimsgroup.com/?l=avalon-dev&m=105914503723538&w=2
After getting some really informative responses I agree that parameterized lookup's aren't a good idea (eg. no type safety passing arbitrary maps to the container, etc).
It would be great to fix up the service selector dilemma though, as it's been container specific for ages and ideally should be specified by the framework api.
I remember when we had the old Avalon 5 emails we looked at having:
Object lookup(String role, Object hint); // I agree hint isn't the best name
Anyone remember the results of that discussion?
Cheers,
Marcus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
