Team, As mentioned earlier, I would like to pull out FOTreeBuilder's ElementMapping initialization from Apps.Driver, and instead encapsulate it within FOTreeBuilder directly.
[Note: Alt-design no longer uses ElementMappings--but this change does not preclude switching to alt-design's method: if we do make such a switch, instead of pulling out ElementMapping code from both Driver and FOTreeBuilder, we'll just pull out the code from FOTreeBuilder.] But, this is a two-vote procedure because something else has to be done first: 1.) Discontinue the dynamic discovery and run-time adding capability of ElementMappings. The code currently allows you to add user-created ElementMappings to the FOTreeBuilder at run-time without changes to the source code. I think we can turn off this feature for two reasons: (a) It doesn't appear to work without source code changes anyway -- I was suspecting, and Peter had confirmed (http://marc.theaimsgroup.com/?l=fop-dev&m=105467992322684&w=2), that dynamically adding mappings won't help unless the code understands the semantics of the new mappings, i.e., what the Area Tree needs to do with them. But users skilled and inclined enough to create user-defined ElementMappings can still do so by modifying the source code. (b) We're a bit overloaded already for 1.0 -- removing run-time ElementMapping configuration will allow us to keep focused on other areas. ("Moving Part Reduction" design pattern, my favorite ;) Here's my +1. 2.) Finally, move the code setting up the default element mappings from Driver class to FOTreeBuilder directly. The Driver class will be ElementMapping-free. Here's my +1. Thanks, Glen __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
