Niclas Hedhman wrote:
>
> 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" );
> :
> }
>
Yes, living as a Merlin user is easy :) Seriously, I know this solution
in Merlin, but I'm talking about the framework that doesn't know
anything about meta information.
Although this gets a little bit off-topic, but imagine you write:
public void service( ServiceManager sm ) {
FootballLocator fbl = (FootballLocator)
sm.lookup( org.hedhman.niclas.sports.FootballLocator.class );
}
(I left out the key for this example), you wouldn't need to declare
the meta info @avalon.dependency anymore. By looking at the code
of the service method the dependency is obvious.
</END OT>
> <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.
Yes, Merlin, but I'm talking about framework :)
>
> > > 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?
>
Two lines and especially the try catch stuff. In some cases
you have to store the selector somewhere just in order to be
able to release the component later on properly etc.
> > > 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.
Yes.
> 2. Passing of auxillary selection information to the container.
Yes.
>
> 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)...
No :) The container doing this, based on the hint is enough for me.
>
> 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?
No, as I don't need a locator (Sorry) and I think this falls into
the category of "too much magic".
>
> I am fishing around the bush, trying to avoid mixing the
> concerns, which I think the locate( Class, query ) does.
Hmm, I don't think so. I agree that it fixes two potential problems
at the same time of the current framework:
1. Use Class as Type, and enforce its use in Framework
2. "Dynamic implementation selection" at runtime for a type
> 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?
My point is, that the container must have a clue. Now, let's take
a step back. Imagine you have a service interface (Football) and
one implementation A. In this case you somehow tell the container
that the implementation A should be used for the Football service.
A component needing the Football (nice example :) ), just looks
it up, but of course has to know how do to this. The simplest
solution imho is to say:
"I want a Football" which I would translate to something
like "locate(Football.class)".
The container knows that it has to deliver impl. A and everything is
fine.
So, the first step we could take now, is to agree that this approach
"locate(Football.class)" is more elegant than
"lookup('org.hedhman.niclas.sports.Football')".
(Again I'm just talking about framework).
If we agree on this we can do the next steps :)
WDYT?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
