Hi, >> Hi Berin, >> I try to understand your ContainerManager, to give >> my 0.02 EURO Cents to improve it. > >Kool beans! It's not done, but it functions....
...and as always, there is never ever a end... >> I just follow the red threads, how it is executed at least. >> >> ContainerManager returns a Container Object by calling the >> getContainer() method. You return a Object and not ContainerObject, >> therefor we nee a extra cast here. Why don't you return just >> a Object of the type Container? > >Two reasons: > >1) The type Container is an interface, not a concrete class >2) Considering all the discussion about being limited to implementing > a Component interface is too binding, I thought it best not to > introduce that limitation here. > >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). >> The returned Container extends AbstractContainer. AbstractContainer >> has initalized all components + handler in the config file and their >> mappings added it into the new bucket map. > >:) 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? >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". >> 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 Application calls the lookup method of the returned >> ContainerComponentManager, >> behind the szene the ContainerComponentManager calls the get(..) method of >> the >> AbstractContainer, which returns a reference to the ComponentHandler which >> matched with the role. It returns again a Object and we need a Cast. Why >> not a >> returning a Handler Object? >> At least some checking happens in the lookup method of the >> ContainerComponentManager >> which I don't understand yet, but at the end this ComponentHandler returns >> a Component. > >The purpose of the ComponentManager is to return a Component. The >ComponentHandlers are still effective regardless of whether we return >Object (as the push is now for framework) or Component. It's a small >price to pay for that future proofing. > > > >> Hmm I see so far some design improvments, please correct me if I'm wrong: >> 1. Think about the explicit Casts in ContainerManager and >> AbstractContainer. >> Are they really necessary? > >Do you have some specific ones you are concerned about? I prefer to >deal with specific types if I can...It just makes things easier. It's >not hurting us *that* much. By removing certain explicit casts, we will >only be gaining a couple more milliseconds on the test time for 50,000 >lookups and releases. see above >> 2. Create a standalone ContainerComponentManager. Here I see the difficulty >> to detach it from AbstractContainer (hmm just create a standalone class and >> pass a reference from the AbstractContainer to it, or?) > >:/ > >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. >> So far so good! > >:) > >Thank you. I look forward to when this can be done and it be much more >elegant than the ECM. Cocoon land too, I swear ;) ~Gerhard "Sorry, but my karma just ran over your dogma." -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
