Glen Mazza wrote:
1.) Discontinue the dynamic discovery and run-time
adding capability of ElementMappings.


(a) It doesn't appear to work without source code
changes anyway -- I was suspecting, and Peter had
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.

The answer is: it depends. If the areas the extension element creates can be handled by the renderer, and the extension is put into places where the FO content model isn't yet enforced by the code, there is no problem to add it without further code changes.

The MathML and Plan samples actually depend on this.

(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 ;)

I don't think dynamic element mapping adds all that much overload.

2.)  Finally, move the code setting up the default
element mappings from Driver class to FOTreeBuilder
directly.  The Driver class will be

-0 I don't think it matters much. If the new API comes to fly, the Driver class will be deprecated anyway.


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

Reply via email to