Hi Keiron

> I agree that mime types would be appropriate to select the output
> format.
> How would you use a mime type to select a special type or an alternative
> renderer or do you think it is unlikely that there would be two
> renderers for the same mime type.
> Some people do have a sub-class of the awt renderer that does extra
> stuff, maybe this could be handled in a better way.

I'd compose the role name using the Renderer interfaces role name
("org.apache.fop.render.Renderer") plus a purpose (in our case the MIME
type, ex. "application/pdf"). An example:

If someone has got his own replacement for some renderer he can change
the component setup XML so the MIME type "application/pdf" references
the custom PDF renderer. Or maybe he/she can use additional attributes
on the mime types such as a non-standard "application/pdf;
type=mycustomtype". Just ideas. It should work, since we don't even have
to parse the mime types. And the blanks in the role name shouldn't be a

Here's an excerpt from Berin Loritsch's Developing with Avalon
concerning role names (from
If we have multiple Components that implement the same work interface,
but are used for different purposes, we have separate roles. A Role is
the Component's purpose in the system. Each role name will start with
the original role name, but the purpose name of the role will be
appended with a /${purpose}. By example we could have the following
purposes for our DocumentRepository: PurchaseOrder and Bill. Our two
roles would be expressed as DocumentRepository.ROLE + "/PurchaseOrder"
and DocuementRepository.ROLE + "/Bill", respectively. 

> On Tue, 2002-06-04 at 08:05, Jeremias Maerki wrote:
> > 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 should hope there is no refactoring required, unless you are talking
> about the maintanence branch.

Well, I'm not up-to-date with the main branch, but I'm not talking about
major refactoring. I meant changing to the LogEnabled, Configurable and
maybe (if necessary) Composable/Servicable interfaces. No big deal!

Jeremias Märki


Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch

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

Reply via email to