Glen Mazza wrote: > 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.
Yes, #2 would be my preference. However, you raise a critical point here. Since a Property object can encapsulate more than one piece of data, and a "get" method can only return one, we may end up having multiple "get" statements needed in some cases to convey the same amount of information. I *think* this should only be true in the cases that Peter has mentioned where the computation cannot be done until more is known about layout. I think these can be handled cleanly either by 1) passing context data to the "get" method that it can either use or ignore as its internal data drives, or 2) getting the FO Tree and Area Tree tied together well enough that the FO object can "see" the Area(s) from which its context is derived, and return the appropriate value. > (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 > tree. > > [1] > http://www.w3.org/TR/2001/REC-xsl-20011015/slice3.html#fo-jc-intro > > > [2] > http://www.w3.org/TR/2001/REC-xsl-20011015/slice1.html#section-N74 2-Formatting I don't think I had noticed this before. It looks like the standard *does* consider the refined properties to be traits. Since a refined value in the FO Tree should be the same as the value used in the Area Tree, that makes some sense. > (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 > processed.) Makes sense. I always like to let the compiler do the work for me, so I would probably first make all of the Property stuff private, recompile, and start fixing compile errors. > 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? If you are talking about the property values, yes, any that are not yet expressed as enumerations, and that can be, should be. If you are talking about using enumerations to distinguish between Property A and Property B, then this gets done automatically, as each has its own "get" method. Victor Mote
