cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: cvs commit: xml-cocoon2/src/org/apache/cocoon/components/xscriptXScriptManager.java
Date Mon, 29 Oct 2001 17:31:30 GMT
On Mon, 29 Oct 2001 09:03:50 -0500, Berin Loritsch <bloritsch@apache.org> wrote:

> giacomo wrote:
> > 
> > On Sun, 28 Oct 2001, Ovidiu Predescu wrote:
> > 
> > > On Sat, 27 Oct 2001 23:02:29 +0200 (CEST), giacomo <giacomo@apache.org>
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 <ovidiu@cup.hp.com>
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message