Hi all,
Sorry for the long post, but looking into fixing bug 39560, I ran
into an obstacle which made me wonder...
Very briefly put, the obstacle was the recalculation/re-evaluation of
the properties when a FO is a descendant of a retrieved marker.
As I have it now, the code related to keeping track of the parent's
column-index is executed only once for every TableColumn/TableCell
(instead of 'as many times as the table is retrieved through a
marker, plus one for the original node as a marker descendant')
OTOH, the related code in ColumnNumberPropertyMaker, which relies on
the above mentioned pieces of code, would get executed multiple times
for descendants of cloned tables. (via FObj.bind() -> Property.get())
In the case of column-number, it is self-evident that absolute/
initial values will never change once the original fragment has been
parsed, so there is no compelling reason for re-evaluation... The
cloned instance variables suffice in this case.
I got around this by making the call Property.get(PR_COLUMN_NUMBER)
depend on whether one of the instance variables of the cell's parent
is (not) null, which makes this more of a dirty hack as a workaround
very specific to this property and the related FO.
Now, this got me wondering whether the whole rebinding process
couldn't be made a bit more intelligent. Instead of blindly resolving
all properties a second (third/fourth...) time, would it be an
improvement if we restricted this to, say inherited properties and
expressions containing function calls that refer to inherited
property values (and what about relative numerics, percentages)?
To fix the bug, I was just looking at ways to exclude *this* property
from being recalculated multiple times. If there are other such
properties, then generalizing this approach could prove to be
beneficial since in the general case, we have no idea of the
complexity of the calculation.
Note that the reverse might also be applicable: there are certainly
properties/expressions that we don't want to be evaluated at parse
time, since the results are going to be replaced anyway --avoiding
these operations could be an improvement in cases where numerous
markers are never retrieved.
Not sure if it would mean much, but every little bit helps --
especially if efficiency on arbitrary document sizes and structures
is a long-term goal-- so I am going to look into generalizing this. I
was thinking in the direction of adding a boolean member to FObj that
is switched when the FO is cloned. The bind() method can then be
split up into two different blocks, one for the original context --
marker-- and one for the retrieved-marker context... as such, every
FObj or clone can decide for itself which properties need to be re-
bound from the stored propertylist.
In the meantime, if anyone immediately sees other properties that
could benefit from this, or has neat ideas related to these matters,
feel free to share your thoughts.
Later,
Andreas
- Concerning markers & rebinding properties Andreas L Delmelle
-
