cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Avalon explainations
Date Thu, 10 Aug 2000 12:59:12 GMT wrote:
> 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.
> 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.

These statements only hold true for the Block level.  Within a
Block we will still use the familiar framework that Cocoon uses.

> > I've got several questions:
> >
> > 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.

If the ImageReader classes read the image's header to determine which
type of image it is, then it would probably be best to return the
ImageReaderFactory class from a ComponentManager.

Inside the ImageReaderFactory, you can access the image-readers through
a NamedComponentManager using the class names as the type (unless you
wanted a shorter name).  The framework assists in many areas, but
be careful to use the right tool for the right job.

The point is do what works.  I don't forsee the ComponentManager classes
being removed from within blocks any time soon.

View raw message