On Wednesday 14 April 2004 17:05, Carsten Ziegeler wrote:
> How do you know what service "red-football" returns? (Ok, of
> course *you* know it), but anyone else seeing the above
> lookup might not know it.
Well, I am Merlin-user, and I think its solution is fairly elegant;
/**
* @avalon.dependency key="locator"
* type="org.hedhman.niclas.sports.FootballLocator"
*/
public void service( ServiceManager sm )
{
FootballLocator fbl = (FootballLocator) sm.lookup( "locator" );
:
}
<snip content="ROLE elaboration" reason="agree" />
> In addition by passing in the interface class, the container
> can check if the correct component (implementing the interface)
> is returned etc.
Merlin will ensure that the returned type in the above is a FootballLocator
and nothing else - guaranteed.
> Using custom keys like "red-football" that have no semantic
> meaning is imho not so good.
Ok, fair enough, I agree on that...
> > FootballLocator fbl = (FootballLocator) sm.lookup(
> > "footballs" ); Football ball = fbl.locate( "red" );
>
> Yes, we already have this approach by using ServiceSelectors
> which is way to complicated and leads to ugly rather ugly code.
Ugly? :o) Two lines instead of one? Or is it related to try{}catch{} stuff?
> > I think I don't understand where the Framework needs to be
> > involved, and that is what I am trying to understand...
>
> You can do everything already today without any problems, using
> ServiceSelectors etc. But imho these approaches are not elegant
> and in no way standardized. Introducing this new locator is
> a concrete and clear way.
Ok. ServiceSelectors are somewhat different, and that difference is the reason
why they are (and will remain) deprecated.
I think you are bringing up 2 issues;
1. Use Class as Type, and enforce its use in Framework.
2. Passing of auxillary selection information to the container.
I also assume that you are looking for a way so that for each Type, one can
define a LocatorHandler (didn't want to use the word Selector, but in
principle same thing)...
How about something like this?
If the component declare a method "someFunkyName()" which takes a single
argument which is a subinterface of "Locator", the container is responsible
to provide an implementation of such Locator type to the component.
public class MyComponent
{
public void locatorService( FootballLocator fbl )
{
Football ball = fbl.locate( "red" );
}
}
Looks very easy for the component author.
Do you think that would that be of help?
I am fishing around the bush, trying to avoid mixing the concerns, which I
think the locate( Class, query ) does. The query still have to be passed off
to someone else (container have no clue what to do with it), so why not
inject "someone else" to the component?
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
