You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/10/29 15:03:50 UTC

Re: cvs commit: xml-cocoon2/src/org/apache/cocoon/components/xscriptXScriptManager.java

giacomo wrote:
> 
> On Sun, 28 Oct 2001, Ovidiu Predescu wrote:
> 
> > On Sat, 27 Oct 2001 23:02:29 +0200 (CEST), giacomo <gi...@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.

----------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org