On Jun 11, 2006, at 03:56, Andreas L Delmelle wrote:
Just FYI:
Some more follow-up on the problem WRT percentage resolution in
markers:
<snip />
My suspicion that the percentage resolution is done purely via the
FOs pointed to by the PropertyList turned out to be correct, and
what I'm currently looking at is rather nasty... 8)
The PropertyLists stored in the marker are created based on the
original FOs, which means, IIC that all LengthBases or instances of
derived classes in that PropertyList get a reference to the
original FO.
Later on, when RetrieveMarker is resolved, the marker descendants
are cloned and the clones are then bound to these PropertyLists
(=Map descPLists in Marker.java).
As a result, the percentage resolution tries to climb a tree of LMs
that was never created (there is no LM corresponding to the
original FO)
I think the correct way to solve this, is to have the Markers store
references, not to the PropertyLists, but to the original Attributes.
pList.addAttributesToList() should be called only after the clone is
created.
IOW: simply defer that call for every passing node when
'IN_MARKER_CONTEXT' (=non-existing variable, member of Flow?), and
instead store the Attributes of the Marker descendants in the
HashMap. The PropertyList should also be instantiated only during the
cloning process (the clone needs to be passed to its constructor to
make everything work correctly).
The intention of the MarkerPropertyList subtype seems correct, but it
doesn't go far enough (should store the original Attributes instead
of the parsed explicit properties; once they're parsed the damage is
already done, so to speak).
Later,
Andreas
