I was looking at how the Driver class initializes its FOTreeBuilder instance with formatting object ElementMappings. This currently occurs in three ways:
1.) Driver explicitly adds three default element mappings (FO, SVG, FOP extension) to its FOTreeBuilder instance 2.) Driver searches META-INF/services directory for additional user-defined extension mappings, adds them 3.) Driver provides two forms of addElementMapping() functions for embedded users to explicitly add more ElementMappings. (Jeremias explained #2 and #3 process here: http://marc.theaimsgroup.com/?l=fop-user&m=104256122918946&w=2) I see two possible changes for 1.0dev: 1.) For standard reasons of encapsulation/modular design, also potential future deprecation of the Driver class, I would like to make the FOTreeBuilder more standalone. In particular, have (1) and (2) done within the FOTreeBuilder code itself as part of its responsibilities. For (3), we may still need to retain the Driver addElementMapping() functions for backwards compatibility. But I would like to have them just wrap new functions of the same name in the FOTreeBuilder code: i.e., Driver's: public void addElementMapping(ElementMapping mapping) { mapping.addToBuilder(treeBuilder); } will now be: public void addElementMapping(ElementMapping mapping) { treeBuilder.addElementMapping(mapping); } 2.) Moving forward, I would like to see the ElementMapping interface deprecated, and instead have the mapping classes extend an "ElementMap" base class. Features of this base class would be: a) This base class would have two public member variables: (1) the URL and (2) its fOObjs HashMap, for the FOTreeBuilder to use for attaching the ElementMap. b) Instead of the ElementMapping-implementing class attaching itself to the FOTreeBuilder (via "addToBuilder" function defined in the interface), the FOTreeBuilder will do the attaching of the ElementMap subclass. (This will allow the FOTreeBuilder code to do some error-checking prior to accepting the extension class.) c) The ElementMap base class and its subclasses will have no reference to an FOTreeBuilder object. They will be standalone, can be attached to things besides an FOTreeBuilder, and will work even if the FOTreeBuilder class is removed. Let me know if this seems advisable--if desired, I can try to submit patches on one or both of these. Thanks, Glen __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
