Gerhard Froehlich wrote:
> Hi,
>
>>The ContainerManager will create any arbitrary Container. Whether it
>>uses the Container interface directly i.e. Container.WORK_DIRECTORY,
>>or it extends it is up to the developer.
>>
>>You will have to cast--and in the end I think this is best.
>>
>
> Hmm well yes and no. It's OK that the Component interface disappears
> at the end.
> But this is more "how to implement Avalon", because I see the user running
> first into a ClassCastException here. You force in the code of the
> ContainerManager:
>
> private Container m_containerInstance;
>
> and you return Object, IMHO that's not really "typesafe" (I know Java is
> typesafe, but I guess you know what I mean).
Oops. I need to make m_containerInstance an Object....
Seriously, Container is not a useful interface to interact with.
Therefore, the user Must cast the instance to a useable interface.
There is no way of creating a one-size-fits-all model (I wish there
were). Every invoker (command line, servlet, embedded block, etc.)
will have a different work interface that they use for the container.
>>:) It can extend AbstractContainer. The purpose of AbstractContainer
>>is to simplify the initialization process--but be flexible enough to
>>retrofit your custom mappings on top of it.
>>
>
> Hehe as you see I oriented myself at the TestCase. Can you describe
> me in short words, how we would implement this new beans in Cocoon.
> Writing our own Container and integrate the CocoonComponentManager, I
> guess?
Well, the ComponentManager implementation would *still* be the
ContainerComponentManager. The only difference is that the Cocoon
container would recognize that certain roles will be ComponentSelector
accessed, and it will have a reference to the ContainerManager for the
Sitemap. Remember that the Sitemap is also a container in its own
rite.
>>In the end it is not required. Anyone is free to specify any arbitrary
>>class. However, if it wants to take advantage of the ContainerManager's
>>work, it should implement Contextualizable.
>>
>
> Yep I see. But see my points above "typesafe".
I will fix that problem. Until we have generics in java, we will still
be forced to cast.....
>>>The Container returns the ComponentManager. Behind the szene
>>>following happens. AbstractContainer creates a ContainerComponentManager,
>>>which is a inner class in the moment. I guess it will be a real
>>>ComponentManager
>>>in the future, or?
>>>
>>Its implementation is tied to AbstractContainer, so the virdict is still
>>out on that. I do *not* want to expose public get/has methods on the
>>AbstractContainer, which is what would be necessary if the
>>ContainerComponentManager is external. It would have to be coded to an
>>interface (which demands public methods).
>>
>
> That means, for me as user I have to implment my own Container and integrate
> then my own ComponentManager to get the full features. Sry but it seems
> I didn't understand it full.
>
> However here I see space for improvement, maybe we can take some labor from
> the user and make it more pluggable.
:)
The ContainerComponentManager/Selector merely delegates its logic to the
Container. Therefore the Container only has to change how the
ComponentHandlers are mapped--or directly override the get/has methods.
If you need to do tricky things, it is still possible--without having
to worry about the ComponentManager/ComponentSelector implementations.
It is easy to write a one-size-fits-all implementation for those.
>>I don't see the ContainerComponentManager being used outside the context
>>of the AbstractContainer. The only reason for separating it would be to
>>shorten the length of the AbstractContainer.java file. I like the
>>ability to have tight controls on access points for instantiating the
>>ContainerComponentManager. It's whole purpose is merely to delegate
>>calls back to the Container.
>>
>
> Hmm OK I understand you here...but as mentioned above, maybe there is way
> to take away some labor of the user and make it more pluggable without
> getting unsafe.
>
> Just to think about.
I don't think the ComponentManagers/ComponentSelectors themselves should
be made pluggable. The default behavior for the implementation is all
contained in the Container, and if that needs to change it is easy to
do so.
--
"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]>
