Glen Mazza wrote:
> 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.
What about instream-foreign objects that get passed through? SVG is the only
one I know of, and it is hard-wired in already, but I'm not sure that this
capability should be lightly tossed. Please explain why this is a
prerequisite for the proposed move.
> (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 ;)
If it is gumming up the works, then OK. Otherwise, why remove it?
> Here's my +1.
I'll abstain pending further clarification.
> 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.
+1 (on part 2).
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
