> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
>
> Hi Leo,
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > No. Only if you allow the CM to interpret the Context. If you let the CM
> > pass the Context along to a ComponentSelector, there is no such problem.
>
> Man! The ComponentSelector is an "indexing" strategy.
Paulo,
yes, but not CM wide, mon!
> I also mentioned having a replaceable "indexing" strategy that you might
> change for specific Domains. Go back a bit on this thread (or in the
> [RT] Is Poolable Harmful?) and you will find it.
Yes, but if I understood you correctly (and looking below, I did), you had
an indexing strategy that was CM-wide.
> However, I just want a CM wide "indexing" strategy, which on some
> implementations might even delegate some cases to... (tadaaaaaaa)
> ComponentSelectors.
By delegating this responsibility to CS, you allow components from
different domains to exist in the same CM. If the whole CM has one
strategy, then you can not do this.
With two lookup methods: lookup(role) and lookup(role,context), you can
be certain that no matter what strategy is used, you will get back an
interface of type role. With my proposal, you would also be certain that
the context is interpreted in a predictable way, irrespective of the CM
implementation.
With your proposal, there indexing strategy is part of the contract
between the component, the CM, and the user of the component. With my
proposal, it is between the component and the user. The CM is utterly
unaware of the indexing strategy used, and you can have components
that require different indexing strategies in one CM.
What if component A requires strategy a, and component B requires
strategy b? With your method, A and B can never be used together in
one CM. With mine, they can.
> In the end, what I miss is this CM wide "indexing" strategy and I do not
> see a reason to have 2 lookup methods in the interface.
>
> Notice that in most implementations
Which isn't good enough. If you have defined a CM interface, then you must
specify enough to allow one to make assumptions about *all* implementations.
This is my main problem with your strategy.
> calling lookup("role") should work
> since everybody will try to reuse de default ECM.
>
>
>
> > Since the domain-specific interpretation is hidden away in the
> CS, the CM
> > need not be changed.
> >
> > I imagine something like this configuration:
> >
> > <myapp>
> > <!-- Straightforward -->
> > <component role="my.Component" class="my.ComponentImpl"/>
> >
> > <!-- Selector in use -->
> > <selector role="my.SelectedComponent" class="my.ComponentSelector">
> > <component hint="key=abc" class="my.SelectedComponentImpl1"/>
> > <component hint="key=def" class="my.SelectedComponentImpl2"/>
> > </selector>
> > </myapp>
>
> I hate this selector configuration.
>
> I have situations where I want to declare some of the available
> implementations in one config file (all the standard components for
> a domain) and extend that role with some more implementations in
> another file (the components specific to ONE application developed
> for that domain).
Then that could be solved by merging configurations - I believe Berin was
up to something like that a while ago for Cocoon.
> AGAIN: I also want a CM and even some basic ECM decoupled from
> domain stuff, otherwise I can not reuse them.
But you want to decouple the CM interface from the component domain.
A CM manages Components, as defined by the Avalon framework, and nothing
else.
However, if you want the ECM (the implementation) to manage things other
than components, while still letting it implement a CM interface,
then I'm with you.
> However, your solution can NOT be less domain aware than mine.
>
> I really do not see how what I propose restricts you in any
> way.
It does not restrict me, but it also weakens the contracts I'm using
to build my components on. It is so flexible as to be unusable, since
I have no idea whatsoever what I will get back from a lookup(Object)
call. I'm restricted to passing something in, praying that the indexing
strategy used in the CM will give me the right interface back. With the
interface proposed by Berin, I know that I will get the right interface
back. With my proposal, I can even predict (if I have written the CS),
how the Context will be interpreted.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
