Just an idea that popped in my head. I was thinking of the access to a FONode's properties from the layoutengine, and it became apparent to me that ATM the approach is not too flexible: each subclass has its own little set of private instance methods and public accessors. This makes it hard to implement new properties or deal with extension properties in a generic way.

In ancient times, each FO had a full PropertyList, so the properties could be queried via a generic get(PROPERTY_ID) accessor that was simply a proxy to the PropertyList's corresponding get(). This was, however, a much less efficient approach than what we currently have.

My suggested best-of-both-worlds would be the addition of (at least) one new type, which would store the applicable properties for a FO.

Starting with an interface:

public interface FOProperties {
    Property get(int);
    Property get(String);

Each of the particular FO classes can then define its own implementation, which stores the applicable properties and maybe, for some FOs (like FOText!), this implementation can simply search the ancestors, instead of having to allocate space for properties that are always identical and can't be specified anyway...

The downside would be the loss in convenience, for instance, where we now have individual accessors returning a Length, LengthRange, Numeric... Not sure how I would address this, yet. :/

If anyone has suggestions, feedback is welcome.



Reply via email to