ComponentManager

[Torsten Curdt <tc...@dff.st>]

At least for me it would be useful to have a static
method to get to the cocoon component manager instance.

Not all of our classes are really what I would characterize
as a component. So I need to pass the component manager
to all my classes.

Isn't it reasonable to have a static access to the
component manager as there is e.g. for the logger?
Or should this be considered a bad design/idea?
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: ComponentManager

[Berin Loritsch <bl...@apache.org>]

Torsten Curdt wrote:
> 
> At least for me it would be useful to have a static
> method to get to the cocoon component manager instance.
> 
> Not all of our classes are really what I would characterize
> as a component. So I need to pass the component manager
> to all my classes.
> 
> Isn't it reasonable to have a static access to the
> component manager as there is e.g. for the logger?
> Or should this be considered a bad design/idea?

No.  It is not necessary for a class to be a Component for
it to implement Composable.  You would have to manage the
passing of the ComponentManager yourself, though.

Regarding the design of the ComponentManager, it is supposed
to be assigned using the Inversion of Control pattern.  This
helps guarantee a level of security in that access to a
Component within a ComponentManager has to be managed.  We don't
want to allow rogue code to obtain instances to components.
This is bad.  While nothing is foolproof, the IOC approach does
make obtaining the ComponentManager more maneagable, with known
interactions.

The Logger was designed to be used with Avalon, and separate
from Avalon.  Also, the impact of obtaining a Logger by
malicious code is significantly less than that of obtaining
a ComponentManager.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org