Leo Simons wrote:
>
> I very much prefer a simple pluggable approach, where you
> perhaps start with the most basic semantics (according to me
> thats Objects, ie HashMap semantics, according to Berin its
> definately Strings), but can support any other semantics by
> writing like 20 lines of code and 2 lines of configuration file.
>
> > That way you could create a scheme
> > which could handle a number of different lookup mechanisms.
>
> Well, URLs are ASCII strings. Not everything is easily or
> conveniently transformed into an ASCII string...
>
Ah nice, now we have three possibilities :)
Now, the way Avalon was used for years is to define a component
interface like
interface GreatComponent {
String ROLE = GreatComponent.class.getName();
..
}
and then you do a lookup using GreatComponent.ROLE (a String).
In the case that you may have several different implementations
playing this role, you first lookup a selector:
lookup(GreatComponent.ROLE+"Selector") and then lookup
the component from the selector using a key (hint).
So, I think it is much easier to write:
lookup(GreatComponent.class) for the first case and
lookup(GreatComponent.class, key) for the second one.
So by using a class as the definition you see by looking at the
code which component you want.
But more important is that the container can return an instance
of the class the client requests which helps in heavy class loading
scenarios.
In fact this last feature is the killer argument against all other
current containers for Cocoon. We need this :( [or :)?]
But apart from Cocoon, I personally like the Class approach much
more than the String based one. You can see by the code what is
happening. You can't obfuscate your code by writing lookup("mr.president");
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache Excalibur Project -- URL: http://excalibur.apache.org/
