Also, while I used fo:element constants in my
experiment, it is clear to me that such an approach does not work well for
extension elements.
[Glen Mazza]
Oh no--I hope you don't mean we have to revert to
strings for those?
No, not at all. It is just that the element id's for extensions must be assigned dynamically. Something along the lines of:
in FONode (or anywhere else):
private static int _elementId = Constants.ELEMENT_COUNT;
synchronized public static int makeElementIdentifier() {
return ++_elementId;
}and in each and every extension subclass of FONode this boilerplate:
private static int elementId = makeElementIdentifier();
public int getElementId() {
return elementId;
}Using that logic, property constants wouldn't work either, right? (because extension elements can have different properties).
At the moment, my performance experiment does not support extension properties either, but it can be added like this:
- An API that allow the extension to assign values to its property identifiers dynamically, like elementId above.
- An API that allow the extension to inserts its properties into the bitset of the parent elements. Otherwise extension property values can not be inherited from the normal fo: elements. (BTW, this is a good argument for calculating the full inheritance bitset at runtime).
A change to int elementId's and properties along the lines of my experiment, would mean a somewhat higher burden on extension writers.
regards, finn
