FOP Developers:
This has been kicked around recently, but I realized that it may be beneficial to go ahead and propose a change to get things going. The issue of how Properties are stored in the FO Tree is in play. Since we now have FO Tree pretty well isolated, I see some benefits to nailing down an API for it that should be durable enough to work for any scheme that is used for storing property values.
Proposal: I propose that public "get" methods be used to retrieve FO Tree property values, and that the data behind these values be made as private as possible. The methods should be given a name based on the XSL-FO Standard. For example, the "max-width" property should be accessed using the method "getMaxWidth". The values returned should be the "refined" values.
Discussion: 1. The purpose here is to separate the storage of the property values from their presentation (API) to the rest of the system. This opens the door for later changes to the storage without disrupting the remainder of the system. 2. This could perhaps be implemented for now only in FObj (??). 3. This is not directly relevant to the question, but needs to be addressed from the "big picture" standpoint. With the FO Tree mostly isolated, and LayoutStrategy implemented, the issue of whether a certain feature is implemented or not moves from the FO Tree to the specific LayoutStrategy. Each LayoutStrategy eventually needs to track which objects and properties it supports. The FO Tree should always store and return the data, without regard to whether it can be used or not. In the future, our properties.xml file, "compliance" page, and perhaps other things need to handle this. The LayoutStrategy needs to be the entity that reports on whether a feature is supported (perhaps using a scheme similar to properties.xml). 4. If accepted, this would be a great project for one of the new developers to tackle. I don't mean to volunteer anyone, but it might be a good "feet wet" project.
In alt.design, all of the property values are implementations of fop.datatypes.PropertyValue. Every PropertyValue must be able to report its type as an int. Every PropertyValue must also have a Property with which it is associated, and must be able to report this, again as an int. The set of property values relevant to a particular FO are available in a sparse array, accessible by the int index corresponding to the Property. That, it seems to me, is as far as the FO Tree can take things. What are the "get" methods going to return? In alt.design, they will always return a value of type PropertyValue. This proposal seems to imply that the type returned by the accessors will depend on the type supported by the Property. Take MaxWidth. What value will be returned? An int, representing the number of millipoints? An Integer? A Length object? What happens when the width is, as yet, unresolved, because it depends upon the resolution of the width of a reference area in the Area Tree? The value is not undefined, just unresolved. When the FO Tree interacts with the Area Tree, the length will be resolved. But the Area Tree may be re-laid, in which case the value will revert to unresolved.
The resolution of properties within the FO Tree has dependencies on the resolution of areas in the Area Tree.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
