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:
"org.apache.fop.render.Renderer/application/pdf"
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
problem.
Here's an excerpt from Berin Loritsch's Developing with Avalon
concerning role names (from
http://jakarta.apache.org/avalon/developing/framework.html):
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!
Cheers,
Jeremias Märki
mailto:[EMAIL PROTECTED]
OUTLINE AG
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]
