Changes between Version 3 and Version 4 of Ticket #7381, comment 5


Ignore:
Timestamp:
Nov 12, 2012, 2:19:50 AM (9 years ago)
Author:
bill
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #7381, comment 5

    v3 v4  
    55There are a number of back-compat issues with changing this in 1.x, including:
    66
    7 1) dependent properties
    87
    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
     81) unwanted inherited setters
    129
    1310Classes 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.
    1411
    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:
     12Many 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:
    1613
    1714{{{
    … …  
    2219
    2320
    24 3) existing setters that don't work with falsy value
     212) other existing setters that don't work with falsy value
    2522
    2623For example:
    … …  
    3532If _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.
    3633
    37 Nowadays though _WidgetBase has the nonEmptyAttrToDom() factory, used like
     34Nowadays _WidgetBase has the nonEmptyAttrToDom() factory, used like
    3835
    3936{{{
    … …  
    4138}}}
    4239
    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.
     40nonEmptyAttrToDom() 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
     423) other issues
     43
     44In 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
     46Although 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