Changes between Version 3 and Version 4 of Ticket #7381, comment 5
- Timestamp:
- Nov 12, 2012, 2:19:50 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #7381, comment 5
v3 v4 5 5 There are a number of back-compat issues with changing this in 1.x, including: 6 6 7 1) dependent properties8 7 9 In for example !ComboBox, {{{new ComboBox({value: "foo"}) is problematic because set("value", "foo") will be called but also set("item", null) will be called, and the latter will override the first. Although we have code to make sure that parameters to the constructor are executed after default setters, I'm seeing this manifest itself on IE8 (but for some timing reason not on FF) where the first !ComboBox in test_ComboBox.html ends up with a blank value. 10 11 2) inherited setters 8 1) unwanted inherited setters 12 9 13 10 Classes like Button define a _setValueAttr that accesses this.valueNode. Subclasses like !ScrollingTabControllerMenuButton inherit that setter, but don't define this.valueNode. Thus you get an exception. 14 11 15 Many of these cases can be handled in _WidgetBase _applyAttributes() by checking if the attach point is set or not, but that won't handle the case of actual custom setters (in dijit or customer code)like:12 Many of these cases can be handled in _WidgetBase _applyAttributes() by checking if the attach point is set or not, but that won't handle the case of actual custom setters, in dijit or customer code, like: 16 13 17 14 {{{ … … 22 19 23 20 24 3)existing setters that don't work with falsy value21 2) other existing setters that don't work with falsy value 25 22 26 23 For example: … … 35 32 If _setDirAttr("") were called at construction, it would set this.domNode.dir to "", an invalid value. The correct behavior is to not set the dir attribute at all, or better, to call removeAttribute("dir"). There were a bunch of attributes like that, especially relating to form widgets. 36 33 37 Nowadays though_WidgetBase has the nonEmptyAttrToDom() factory, used like34 Nowadays _WidgetBase has the nonEmptyAttrToDom() factory, used like 38 35 39 36 {{{ … … 41 38 }}} 42 39 43 nonEmptyAttrToDom() will call setAttribute() or removeAttribute() as appropriate. So while some widgets with custom setters would certainly be broken by "fixing" this ticket (and thus some people would complain about breaking backwards compatibility), it might not be as big an issue as I thought. 40 nonEmptyAttrToDom() will call setAttribute() or removeAttribute() as appropriate. So something like that would need to be done for any custom setters that don't currently handle falsy values correctly. 41 42 3) other issues 43 44 In for example !ComboBox, on IE8 (but for some timing reason not on FF), the first !ComboBox in test_ComboBox.html ends up with a blank value. 45 46 Although we have code to make sure that parameters to the constructor are executed after default setters, so that the null item shouldn't override the explicitly specified value, it's still failing for some reason