On Mon, 29 Oct 2001 09:03:50 -0500, Berin Loritsch <[EMAIL PROTECTED]> wrote:
> giacomo wrote: > > > > On Sun, 28 Oct 2001, Ovidiu Predescu wrote: > > > > > On Sat, 27 Oct 2001 23:02:29 +0200 (CEST), giacomo <[EMAIL PROTECTED]> wrote: > > > > > > > On Fri, 26 Oct 2001, Berin Loritsch wrote: > > > > > > > > > > /** > > > > > > * Return the <code>ComponentManager</code> managing this instance. > > > > > > * > > > > > > * @return a <code>ComponentManager</code> value > > > > > > */ > > > > > > - public ComponentManager getComponentManager(); > > > > > > + ComponentManager getComponentManager(); > > > > > > > > > > > > > > > This part of the API just caught my eye. Can anyone tell me what purpose > > > > > this serves? I am against this approach as it violates the IoC that we > > > > > have so carefully crafted into Cocoon. If you need a ComponentManager, > > > > > implement Composable! The parent component will/should give it to you. > > > > > > > > > > Basically what I am saying is this: > > > > > > > > > > UNDER NO CIRCUMSTANCES should the ComponentManager be openly available > > > > > to all code in the world. The Components that receive the ComponentManager > > > > > must be carefully managed. > > > > > > > > > > We should probably change this soon. > > > > > > > > I stronly support Berins oppinion on this. Ovidiu, can you explain this > > > > methods usage intention? > > > > > > The method was intended to be used by XScriptObject, which needs to > > > access some Cocoon components, like the XSLTProcessor and Parser. I > > > probably need to rethink the way things work now. > > > > > > In the current implementation, XScriptManager is an Avalon Component, > > > which manages several XScriptObject, which are not Components. I was > > > thinking to make XScriptManager a ComponentManager, and then make > > > XScriptObjects Components. I'm not sure though this would be the right > > > way to do it. Any ideas? > > > > I you say that XScriptManager is managing XScriptObjects you probably > > would instantiate a ComponentManger of your own to add those > > XScriptObjects and thus led them participate to the hole CM world in > > Cocoon. This of course will force to make the XScriptObjects first class > > Components. > > > Another alternative is to make the XScriptObject interface extend Composable. > They are then handed the ComponentManager by XScriptManager. They are not > required to be full Components in that case. Thanks, it looks like this is the way to go, as there are fewer changes to do than in the other approaches. I've implemented it and it seems to be working fine. Thanks all for the ideas. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://orion.rgv.hp.com/ (inside HP's firewall only) http://sourceforge.net/users/ovidiu/ (my SourceForge page) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
