Hi Andreas,
I have little knowledge of the FO tree construction, so I'll perhaps
make naive questions and remarks. I write them in the hope they will
trigger further thoughts.
Andreas L Delmelle a écrit :
>
> 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.
Also, that causes the same code to be replicated in every class; for
example each object for which the margin properties apply will have (1)
a CommonMarginBlock field; (2) a "commonMarginBlock =
pList.getMarginBlockProps();" line in the bind method. This replication
of code is unfortunate as it artificially increases the codebase size,
is more error-prone and more difficult to maintain.
> 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.
To be sure I understand: each object had the very same list of
properties, with null values for the properties wich were not applicable
to it? And the loss of efficiency was due to the indirection caused by
the generic get(PROPERTY_ID) I guess?
> 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...
Hmmm. My understanding of the whole thing is still a bit vague, but
wouldn't that lead to the same code replication as we have now? I'm
wondering if it's not possible to define a restricted number of
implementations of this interface, each applying to a whole set of
similar FOs. Or use object composition: there would be objects dealing
with a particular set of properties (say, border/padddin/background),
and each FO for which that set applies would be composed of the
corresponding object.
Perhaps the flyweight pattern could apply here: only one object for each
set of properties, initializing the correct fields in the FObj. With
some means to automagically wire everything by using marker interfaces
or whatever.
As I said my ideas are still all pretty vague... Also, does anyone have
knowledge about aspect programming? I've the feeling that could apply
quite well here.
> 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. :/
I'm not sure of what you mean? The same property can be accessed in
different ways?
> If anyone has suggestions, feedback is welcome.
I hope what I wrote makes sense :-\
Cheers,
Vincent
