> From: Leo Simons [mailto:[EMAIL PROTECTED]]
>
> Basically, what you are proposing is to create a hierarchy of
> ECMs/ECS rather than a single-level-deep structure, IIUC. The
> advantage of this is that using a tree instead of a map results
> in better maintainability in larger projects. Right?
That would be one possiblity, and I could make some arguments
for this, but what I want is to factor out the "this component
can have subcomponents" behavior from ECM/ECS. That is the primary goal.
Both ECM and ECS now have a getComponentHandler method, for example.
Both of them implements LogKitManageable, Contextualizable etc. for
the sole purpose of passing on the obtained LogKitmanager, Context, etc.
to the component handlers.
What I want to do is create a common superclass for ECM and ECS
and move that code there.
So to split the questions:
1) Should the common code of ECM and ECS be factored out?
This would make it easier to write ComponentSelectors
and ComponentManagers.
2) Is it proper for a component to have subcomponents,
even if that component is not a ComponentSelector?
I'd vote yes to (1) and yes, in some cases, to (2).
> The disadvantage is providing unneccessary functionality in
> simpler setups and degrading performance.
Performance will not be degraded in the current setup. If you
use it, you pay for it, otherwise not.
> You should only break IoC if you really need to.
> Do you?
Well, the jury in my head is out on that one, as well as whether
I am in fact breaking IoC, or just avoiding namespace pollution (roles,
hints) by putting components that I can prove will only *ever* be used by
one component inside that component.
Suppose you have a component:
<component role="General"
class="my.generals.Franks"
use-strategy="my.strategies.Stealthy"/>
So the "General" is set to use a strategy defined by my.strategies.Stealthy,
by instantiating that class and then calling a whatDoIDoNext method on it.
This does not break IoC.
That was how I started. Then I figured that maybe the strategy object
needed to be initialized. And maybe it needed a CM. And a configuration.
And maybe sub-strategy objects.
Finally, I was about to write an entire Avalon lifecycle manager for
the strategy, and since that code already existed in ECM and ECS, well...
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>