Berin, >>>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.
Indeed... >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. <sigh> >>>:) 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. ...back in the code... >>>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..... C# has it, therefor Java too soon ;). >>>>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. Ok I think there are some major understanding issues on my side. ...back in the code... ~Gerhard --------------------------------- Me, Ambivalent? Well, yes and no. --------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
