On Wed, 2004-04-14 at 19:26, Stephen McConnell wrote:
> Bruno Dumon wrote:
>
> > On Wed, 2004-04-14 at 09:59, Niclas Hedhman wrote:
> >
> >>On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
> >>
> >>
> >>>This key should be a simple string,
> >>>so the above could read:
> >>>locator.locate(Football.class, "red");
> >>
> >>Forgive me for a naive question;
> >>
> >>What is the difference of the above, from;
> >>
> >>servicemanager.lookup( "red-football" );
> >>or
> >>servicemanager.lookup( "/footballs/red" );
> >>
> >>Or in the case you need someone else to figure it out;
> >>
> >>FootballLocator fbl = (FootballLocator) sm.lookup( "footballs" );
> >>Football ball = fbl.locate( "red" );
> >>
> >>and the
> >>
> >>public class MyOrdinaryComponent
> >> implements FootballLocator
> >>{
> >> private ServiceManager sm;
> >>
> >> public Football locate( String color )
> >> {
> >> if( color.equals( "red" ) )
> >> return (Football) sm.lookup( "red-ball" );
> >> if( color.equals( "blue" ) )
> >> return (Football) sm.lookup( "blue-ball" );
> >> if( color.equals( "green" ) )
> >> return (Football) sm.lookup( "green-ball" );
> >> return (Football) sm.lookup( "gray-ball" );
> >> }
> >>}
> >
> >
> > Is what you wrote above something that works today in Merlin? I thought
> > the argument supplied to sm.lookup is the name of a dependency, and that
> > you can only be dependent on one implementation of Football?
>
> The above code is a little incomplete - here is a full version:
>
> public class MyOrdinaryComponent
> implements FootballLocator
> {
> private ServiceManager sm;
>
> /**
> * @avalon.dependency type=Football" key="red-ball";
> * @avalon.dependency type=Football" key="blue-ball";
> * @avalon.dependency type=Football" key="green-ball";
> */
> public MyOrdinaryComponent( ServiceManager manager )
> {
> sm = manager;
> }
>
> public Football locate( String color )
> {
> if( color.equals( "red" ) )
> return (Football) sm.lookup( "red-ball" );
> if( color.equals( "blue" ) )
> return (Football) sm.lookup( "blue-ball" );
> if( color.equals( "green" ) )
> return (Football) sm.lookup( "green-ball" );
> return (Football) sm.lookup( "gray-ball" );
> }
> }
>
> Given the above merlin will happly associate instances of Football
> against the respective lookup keys. On the container side you can setup
> directives that control which components get assigned to respective keys.
>
> For example:
>
> <container name="demo">
>
> <component name="red-football" class="StandardFootball">
> <configuration>red-color</configuration>
> </component>
>
> <component name="blue-football" class="StandardFootball">
> <configuration>blue-color</configuration>
> </component>
>
> <component name="green-football" class="StandardFootball">
> <configuration>green-color</configuration>
> </component>
>
> <component name="football-thing" class="MyOrdinaryComponent">
> <dependencies>
> <dependency key="red-ball" source="red-football"/>
> <dependency key="blue-ball" source="blue-football"/>
> <dependency key="green-ball" source="green-football"/>
> </dependencies>
> </component>
>
> </container>
Ah, I hadn't looked yet into manual dependency resolution, didn't know
this was possible. Still, since this requires the FootballLocator to
know about the available implementations on beforehand, this doesn't fit
my needs.
>
> Alternatively - if MyOrdinaryComponent had a dependency on a finder
> facility, it could do this automatically based on matching features
> (providing we expose selection semantics in the model and update finder
> to enable this sort of query functionality).
yep.
Thanks for the info.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
