--- 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 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-N742-Formatting (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.) 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. Glen __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
