DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42014>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42014 ------- Additional Comments From [EMAIL PROTECTED] 2007-04-03 17:26 ------- Thanks for the detailed analysis. > - AbstractSVGLength.setValue() calls > AbstractSVGAnimatedLength$BaseSVGLength.revalidate() to validate the *old* > value of the corresponding attribute Hmm, yes it seems that calling revalidate() before any set method serves no useful purpose. > Note that the final validation will be bypassed if the *old* value was valid > (reset() inhibits the call of invalidate() in attrChanged()), i.e. this does > not throw an exception: You're right. I wonder why. > IMHO, validation should happen explicitly in SVG*ElementBridge.buildShape() > and nowhere else. Synching of XML attribute and SVG DOM values should be > separate from this. Agreed. I'll probably put an explicit, public validate method on the value objects that the bridge calls just before it uses those values to build the graphics objects. This will allow different error-handling behaviour for the bridge and script. > Also consider code like this, which should work if the > element isn't attached to the document yet: > > myWidth.value= someFunctionThatMayReturnNegativeValues(); > if ( myWidth.value < minimumWidth ) myWidth.value= minimumWidth; Yes, according to the bits of the spec you quoted this should be allowed. > BTW, AbstractSVGLength.parse() catches ParseException and sets the length to > 0 unknown units. AbstractSVGLength.getValue() then returns 0 with this > comment: > > // XXX Should we throw an exception here when the length > // type is unknown? > > The answer is "no", but validation at rendering time should check for > invalid units. I think there is a case for throwing an exception here. getValue() is meant to return the length value in user units. If the unit type is invalid, because of a weird DOM attribute value (or doing a .newValueSpecifiedUnits() with an invalid unit type), there's no way to convert it to user units. It's not clear whether some value should be returned or an exception should be thrown. (Actually, the spec is clear that getValue() doesn't throw an exception, but I think it should either be changed to throw or clarified to say what value is returned.) > The behavior of newValueSpecifiedUnits() is even worse: > > elt.setAttribute( "width", 1 ); > elt.width.baseVal.newValueSpecifiedUnits( > elt.width.baseVal.SVG_LENGTHTYPE_NUMBER, 2 ); > > This results in width still being 1 because newValueSpecifiedUnits() does > not call revalidate(), so the other call to revalidate() in reset() resp. > getValueAsString() actually validates the value that has been set before > in setAttribute() and replaces the new value with the old value. Yes, that seems to be broken, too, but only for elements not in the document. I'll take a look at all of this over the easter break. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
