--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Also, as Glen
> has pointed out, there
> is business logic that can be pulled out of these
> code modules back into FO
> Tree where they more properly belong, and where
> duplication and confusion
> can be minimized.

A few more ideas:

(1.) You may find that most of the "properties" that
need to be pulled out of the renderers and layout are
actually Area Tree object traits, so renderers &
layout will probably also benefit from having the Area
Tree having these types of accessor functions.

Now whether you're inclined (1) to allow Area Tree
objects direct access to property list items (like the
FOObj's will have) in order to do whatever business
logic needed to determine a trait, or (2) provide
additional accessor functions--for potentially
non-refined properties--in the FOObj's to shield the
Area Tree from the property manager, both have their
benefits.  I suspect you're more comfortable with (2),
which I can be OK with.  Getting the properties out of
layout and the renderers is more important for me, the
Area Tree less a priority.

(2.) Just as an FYI, as to the issue of whether the
FO's themselves have traits--from our previous
discussion, you were saying that elements have
attributes, FOs have properties and Area Tree elements
have traits, I believe.  That fact is confirmed in the
second paragraph of the Ch. 3 of the spec[1]. 
However, somewhat confusingly, if you look at the
second, third, and fourth diagrams in 1.1.2,
Formatting[2], the spec also refers to traits as the
refined/finished properties of the "refined formatting
object tree".  So in some cases, they do consider 
traits to be both at the finished FO tree and the area



(3.) Another option for us, is that rather than create
all--or most--of the accessor functions first, and
*then* recode the renderers, layout, and possibly area
tree to eliminate any property manager references--it
may be better to work in the other direction.  Hunt
down references in the renderers, layout, and area
tree (in that order, I suspect) to the property
manager, and then create new accessor functions,
one-by-one, to replace those property manager
references found.

This way, we may need to implement only 50 or 60
accessor functions right now, also, we can pound out
the necessary "lessons learned" and layout/renderer
code changes needed while trying to replace the
properties references (for example, the layout manager
classes are sometimes not very good at allowing you to
reference the actual FO item or Area Tree object being
processed.  BlockLayoutManager, for example, does not
make it easy to reference the Area.Block being

Later, when we're ready to implement new
layout/renderer functionality requiring new accessor
functions, we can then add them to the FObj's/Area
Tree as needed.

(4.) Finally, there is a question of replacing the
property string constants with enumerations, which I
believe *all* of us support as a performance booster. 
Any benefits to getting this out of the way *before*
we add the accessor functions?

Anyway, after reading your responses to my concerns as
well as others' concerns, I'm now +1.


Do you Yahoo!?
Free Pop-Up Blocker - Get it now

Reply via email to