cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: cvs commit: xml-cocoon2/src/org/apache/cocoon/components/xscriptXScriptManager.java
Date Mon, 29 Oct 2001 14:03:50 GMT
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.

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


Mime
View raw message