[dojo-contributors] Watchables, data bindings, and get/set

Bill Keese bill at dojotoolkit.org
Tue Mar 9 01:59:59 EST 2010


Yup, makes sense to me too (although I plan to answer your email 
properly soon).    It might break a few people that are currently 
connecting to attr(), if apps start calling get()/set() directly (and 
assuming that attr() calls get()/set() rather than vice-versa).

Won't set() also take an attribute bag like {id: 5, name: "foo"}?   (In 
the future I also thought that we might support get() with no arguments, 
to return all the attributes, although we'd need more metadata about 
which widget attributes are considered official attributes from an API 
point-of-view.)

James Burke wrote:
> On Mon, Mar 8, 2010 at 7:39 PM, Kris Zyp <kzyp at dojotoolkit.org> wrote:
>   
>> Another aspect of this that I would like to propose: I was thinking that
>> it might make sense to a create a new module/class in dojo core named
>> dojo.Stateful that implemented the get/set/watch trio and moving the
>> getter/setter from logic from dijit_Widget (defining functions like
>> _getNameAttr and _setNameAttr for the getter/setter handlers) into
>> dojo.Stateful. Then we could have dojo.Stateful be the superclass of
>> dijit._Widget, which would inherit get/set/watch. Then attr (kept for
>> back compat and some of its useful shortcuts like passing in name-value
>> sets) would be small function that simply delegated to get and set.
>> dojo.Stateful could then be subclassed users code for easy creation of
>> watchable objects, and it might be a useful superclass for object store
>> objects as well (still figuring that out). Does that seem reasonable?
>>     
>
> Sounds reasonable, looking forward to more details/implementation.
>
> James
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>   


More information about the dojo-contributors mailing list