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

Kris Zyp kzyp at dojotoolkit.org
Mon Mar 8 22:39:55 EST 2010

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?

Oh, and in actual response to your email, I think DTL would be cooler
(but probably harder). With DTL (and it's iteration capability), we also
eventually run into defining how to watch arrays, which my need
different notification semantics.

On 3/8/2010 2:05 PM, Mark Wubben wrote:
> On Mar 8, 2010, at 15:04 , Kris Zyp wrote:
>>> * My approach would be somewhat lower level, making sure `object.toString()` would return a unique topic (for that object) I could `dojo.subscribe` to for changes.
>> What would be the advantage of this approach?
> None, really. That's where my thinking was headed last week, as a way to sneak it in. Not the best design, I like your approach a lot more.
> I'm hoping to start implementing this in the next few weeks in the DTL and my API layer. Are you more interested in Dijit's Templated, or does the DTL's DomTemplated make more sense as a place to start?
> --
> Mark Wubben
> http://supercollider.dk

More information about the dojo-contributors mailing list