Hi,
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.
Cheers,
Andreas
