cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric SCHAEFFER" <eschaef...@posterconseil.com>
Subject Re: Avalon explainations
Date Thu, 10 Aug 2000 09:44:30 GMT
----- Original Message -----
From: <donaldp@mad.scientist.com>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, August 10, 2000 11:06 AM
Subject: Re: Avalon explainations


> On Thu, 10 Aug 2000, Eric SCHAEFFER wrote:
> > I work on FOP, and I'd like to make it Avalon aware. Can someone explain
to
> > me how Avalon configuration framework should be used ?
>
> Unfortunately at this current moment the Avalon list is
> going through it. There are some parties who would remove
> the Configuration interface completely and do everything
> through JNDI.
>

????????????
What's the advantage of using JNDI ???
They don't want to use config files anymore ? And what about portability ?

> I am trying to stop that but unfortunately I am lone in my
> venture so it looks like all Configuration and
> ComponentManager could be dropped soon.

I really don't understand why....

>
> In which case it may be best to hold off converting FOP just
> yet to see the outcome.
>
> > I've got several questions:
> >
> > 1- Does the component manager should create a new instance of the
requested
> > component on each getComponent() method call, or does it should only
return
> > an already
> > created instance (during initialization) ?
>
> A ComponentManager just associates particular component
> roles with a component. Usually that means a simple lookup
> in a hashtable or iteration over already existing
> components. The avalon SimpleComponentManager simply looks
> in a hastable and if found it returns it. Otherwise it
> checks if it has a parent ComponentManager and returns the
> role in it's parent's context. This allows a hierarchy of
> component managers.
>
> So really it should only return created instances but if
> there is a particular reason to not behave this way it is
> possible for you to change this. Cocoon itself is the
> ComponentManager and it dynamically creates new components
> during lookup IIRC. However ideally you should populate it
> before you pass it to the component.
>
> > 2- What is the difference between Component and NamedComponent, which
one to
> > choose and why ?
>
> NamedComponent is useful when you have multiple components
> that have same role. For instance Cocoon has multiple
> generators. A normal ComponentManager can't determine the
> difference between all of them, but if you give them names
> you can extract a particular named component from manager.
>
> > In fact, my problem is that, during the FO -> "internal representation"
> > process (layouting process), I need to use a factory class instance.
This
> > factory instance is initialized by a configuration file, but it would be
> > stupid to create a new instance of this class each time I want to use
it...
>
> Sounds like it is crying out for the lazy singlton design
> pattern. ie
>
> class MyClass {
>
>  protected static MyClass singleton;
>
>  public MyClass getMyClass() {
>    if( null == singleton ) {
>      singleton = createMyClass();
>    }
>    return singleton;
>  }
>
> > On the other hand, I understand that for a "parser" component, it would
be
> > better that
> > getComponent() return a new instance...
>
> ComponentManager wouldn't be the right place to get a parser
> then. The ComponentManager may return a factory that you can
> use to create Parsers and that would be an acceptable way to
> use it.
>
> >
> > 3- If you want to give parameters to a component, you write, in the
config
> > file, something like
> > <parameter name="..." value="..."/>
> > But if you want to give it a list of classes, without "names", what is
the
> > "good" way of doing it ?
> >
> > Ex.:
> >     ImageReaders are classes that read image headers, check if it is an
> > image type it can handle, and read the width and height of the image.
> >
> >   <component role="image-reader-factory"
> > class="org.apache.fop.image.analyser.ImageReaderFactory">
> >     <image-reader class="org.apache.fop.image.analyser.GIFReader"/>
> >     <image-reader class="org.apache.fop.image.analyser.JPEGReader"/>
> >     <image-reader class="org.apache.fop.image.analyser.PNGReader"/>
> >     <image-reader class="org.apache.fop.image.analyser.BMPReader"/>
> >   </component>
> >
> > This factory needs parameters, but it's just a list of classes, and not
> > named parameters.
>
> Unfortunately there is no "good" way of doing it. Actually
> there is very little way of doing it all with
> ComponentManagers. I need this functionality for my app so I
> am trying to get this put into a ComponentManager but I keep
> getting told it is bad design practice :<. Thou I will still
> work on them to try and get it allowed :D.
>
> Cheers,
>
> Pete
>
> *--------------------------------------------------*
> | Latrobe University,     |                        |
> | Bundoora, Australia     | Does the name 'Pavlov' |
> | Office: PW220           |    ring a bell ?       |
> | Ex: 2503                |                        |
> *--------------------------------------------------*
>

Thank's a lot.

Eric.



Mime
View raw message