Re: Attribute and SVG object synchronization.

jferraio@Adobe.COM writes:
>>This leads me into another question regarding outstanding references to
>>SVG objects.  What is expected to happen to these references when the
>>attribute's string value becomes updated.  Do these objects simply get
>>detached from their parent elements or do they get updated with new
>>values?  Here's an example:
>>
>>   circle.setAttribute("cx", "50");
>>   SVGLength length = circle.getCx().getBaseVal(); //got a reference
>>   length.getValue(); //returns 50
>>
>>   circle.setAttribute("cx", "100"); //set the 'cx' attribute.  Is the
>>outstanding 'length' reference updated or detached from its parent
>element?
>>   length.getValue(); //returns '50' or '100'?
>>
>>If the objects simply get detached, then the last call would return '50'.
>>If outstanding references are updated then the last call would return
>>'100'.
>
>It should return '100'. The reference is not detached. It is pointing to 
>the active part of the document tree. I'll add a clarification to the
>spec 
>before Proposed Recommendation.

Updating outstanding references is fairly safe in the previous case of
SVGCircleElement, but some element types with complex objects such as
lists seem to be problematic. With SVGPathElement its 'd' attribute is
synchronized with 'pathSegList' and 'normalizedPathSegList', here's a
simple example to illustrate the problem in this case:

	pathElement.setAttribute("d", "M 100 100 C 0 0 0 0 0 0 L 200 200")
	SVGPathSegCurvetoCubicAbs cRef =
(SVGPathSegCurvetoCubicAbs)pathElement.getPathSegList().getItem(1);
//retrieve middle path segment
	pathElement.setAttribute("d", "M 100 100 M 100 100 L 200 200");

After the last call the SVGPathSegCurvetoAbs cRef can't be updated
properly since it is now be a SVGPathSegMovetoAbs reference, the problem
is that the user has already performed a downcast.  The same sort of
problem occurs with CSSValues when oustanding references have been cast
down to a CSSPrimitiveValue or a CSSValueList and then are changed to a
different type [ex. primitive to list or vice versa].  Most
implementations throw some sort of invalid state exception in this case. 
The CSS specification lets the implementation decide what do in this
'corner case' [I think 'stroke-dasharray' is the only property where this
may turn up].  However, in SVG this type situation is a common occurrence
and seems to require a different design [I don't believe this was a
problem when SVGPathSeg was a concrete type, rather than a base case] or
an outline of what is expected to occur in this case. 

Another issue is what happens when the reference no longer exists after a
call to setAttribute? Example:
	pathElement.setAttribute("d", "M 100 100 C 0 0 0 0 0 0 L 200 200")
	SVGPathSegLinetoAbs lRef =
(SVGPathSegLinetoAbs)pathElement.getPathSegList().getItem(2); //retrieve
third path segment
	pathElement.setAttribute("d", "M 100 100 L 150 150"); 
In this case, the third path segment doesn't exist after the last call. 
What is the expected behavior in this case?

Thanks again for the clarification.
----
Blaine

Received on Thursday, 26 October 2000 13:35:36 UTC