Changes between Initial Version and Version 1 of Ticket #12278


Ignore:
Timestamp:
Feb 11, 2011, 10:20:51 AM (10 years ago)
Author:
bill
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12278

    • Property Summary changed from _WidgetBase: custom setter generator to _WidgetBase: fix inheritance issues with attributeMap
  • Ticket #12278 – Description

    initial v1  
    1 attributeMap has issues with inheritance, in that it's hard for a mixin to add/override an attribute in an already existing attributeMap.
     1attributeMap has issues with inheritance, in that it's hard for a mixin to add/override an attribute in an already existing attributeMap.   In particular, the dojo.delegate() call hardcodes the name of the superclass, but mixins can't know the superclass' name.
    22
    3 This can be solved by using custom setters for everything, rather than attributeMap.   However, that makes the code longer.
    4 
    5 Provide custom setter generator as part of _WidgetBase.   Same basic syntax as a single key/value entry in attributeMap.   For example:
     3This can be solved by using custom setters for everything, rather than attributeMap.   However, that makes the code longer.   So, one solution is to provide a custom setter generator as part of _WidgetBase.   Same basic syntax as a single key/value entry in attributeMap.   For example:
    64
    75
     
    1816_setMaxLengthAttr: dijit.das("maxLength", "focusNode")
    1917}}}
     18
     19
     20The downside of this approach is that we lose the meta-data, which would be a problem if (like in cujo) attributeMap could run in reverse, reflecting DOMNode changes (like clicking a checkbox or typing into an input) back into the widget javascript object.
     21
     22Doug's suggestion was to change:
     23
     24{{{
     25attributeMap: {foo: "", bar: "focusNode"}
     26}}}
     27
     28into something like:
     29
     30{{{
     31_fooAttrMap: "",
     32_barAttrMap: "focusNode"
     33}}}