avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: Points to the new ContainerManager
Date Wed, 20 Feb 2002 15:00:43 GMT
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message