Sounds like the right approach, since the property inheritance needs to
be going up the hierarchy after the retrieve-marker has been resolved. I
hope it's not too difficult to implement. I haven't taken a closer look

On 11.06.2006 15:28:57 Andreas L Delmelle wrote:
> 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
> > 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

Jeremias Maerki

Reply via email to