The MIME types for renderer selection is not a new idea. But I don't
know anymore when it came up for the first time.

The idea is to eliminate the hardcoded references to the renderers. That
way it's easier to include new ones or special-purpose renderers
subclassed from existing ones. Instead of wiring the renderers to FOP
using Java code we will do it using XML, or more concrete: The component
setup XML which will be used to build the Avalon-style
ComponentManagers/ServiceManagers. The MIME types could then be used as
role names used to lookup the renderer component (See Avalon docs for
roles, component lookup etc). As for subclassing (I'm not sure what
exactly you're referring to), we won't need to change the current class
hierarchy as far as renderers are concerned. Only some cleaning up and a
little bit of refactoring will be required. The only big thing we change
is the way we get the renderer.

> I'd actually like to hear more about this.  I like the idea at first
> seems like it might result in a cleaner codebase...but I
> really would like to hear more on how MIME-types could be used to
> replace the subclassing technique.  Jeremias, are you suggesting a
> monolithic class for handling all outputs that switches its logic based
> on a MIME-type argument specifying output format?
> -----Original Message-----
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 03, 2002 3:05 PM
> Subject: Re: Exploring the FOP API design space
> Jeremias Maerki wrote:
> > - I'd like to work more with MIME-types for specifying the output format
> >   instead of subclassing a class for each output format. This may help
> >   to reduce dependencies.
> Interesting.

Jeremias Märki


Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to