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
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

Here's my +1.


Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

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

Reply via email to