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 13:35:35 GMT

----- Original Message -----
From: "Berin Loritsch" <bloritsch@infoplanning.com>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, August 10, 2000 2:59 PM
Subject: Re: Avalon explainations


> donaldp@mad.scientist.com 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.
>

Sure...

> 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.
>
I'm not sure to understand you.

My ImageReaderFactory uses a list of classes that implement the ImageReader
interface. It only asks each of its ImageReader instances to try to read the
image headers. If an ImageReader instance can read it, the image is of the
type the ImageReader can handle. For a Gif image, there's only one
ImageReader class. But using a configurable factory enable users to add
their own image readers (for other image types by example).

So, parameters are really a list of classes, of type ImageReader.

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

Ouf...


Eric.



Mime
View raw message