Leo Sutic wrote:
>
>>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.
Yes, but don't call it AbstractContainer. It will confuse things
when the new ContainerManager/Container code is ready for prime
time.
>
> 2) Is it proper for a component to have subcomponents,
> even if that component is not a ComponentSelector?
Yes! Absolutely! That is one of the strengths of design
for Avalon. Containers can container Containers. A Container
is merely an object that holds and manages components.
> I'd vote yes to (1) and yes, in some cases, to (2).
Just use proper judgement. For example, decision trees can
be developed using recursive methods and a snippet of the
configuration tree that has the information in sub configurations.
That was your original issue.
However, in Cocoon's case (which is a perfect example),
the Cocoon component is (should be) a container, and each mountable
sitemap is (should be) a container. As you can see, there is a
natural heirarchy of containers.
>>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.
;P The ExcaliburComponentManager needs some work to become efficient.
>>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.
IoC is ensuring that the container controls the child. The child should
not initiate communication with the container. In essence, the child
only responds to the container.
> 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.
True.
> 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...
Nothing stops you from directly using the ComponentHandler classes. I
would suggest you make all of them ThreadSafe, so you don't have any
funny logic and make things easy on yourself....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
