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

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


A few more comments/questions:

> I wanted to propose having a pattern of providing the ability to monitor
> stateful objects in dojo with a watch() method. The watch method would
> be based on Mozilla's Object.prototype.watch [1]:
> obj.watch(propertyName, callback); // monitor a property
> or
> obj.watch(callback); // monitor any property change for that object
> The two primary types of objects that I would like to be able to monitor
> are widgets and data store objects. We have recently discussed using a
> different data/object store approach whereby data store objects could be
> provide a consistent set of methods, and watch() could certainly be one
> of them. We could also easily add watch to dijit._Widget and deliver
> notifications to listeners for any attribute changes. The ability to
> watch an object would be discerned with feature detection (the presence
> of obj.watch), but would hopefully be available at least on all widgets
> (although user objects could implement this ability as well).
>   

Sounds cool, seems to supersede connections to widgets' attr() and 
onChange() methods.

How would this be used with declarative widgets?

> One of the primary motivations for this design, is would enable building
> functionally reactive "live" templating engines or data-bindings on top
> of Dojo. The concepts of functional reactive design (or data-bindings)
> have been demonstrated in other projects like Flex, Flapjax [2], and Fin
> [3]. There recently has been interest expressed in developing a template
> language with these type of data-binding capabilities that could run on
> Dojo, where one could write something like:
> <div>${obj.foo}</div>
> or
> <div>${obj.get("foo")}</div>
>
> And the variable/object property would be evaluated when the template is
> executed, and the templating engine would then automatically "watch" the
> obj's foo property for any changes and automatically rerender the
> template when the value changes. This is a powerful concept because it
> can remove a significant amount of user code for event propagation and
> rerendering.
>   
Sounds cool.  DTL already does this but having framework support too is 
a good thing.

Also, attributeMap is already designed for this purpose, it essentially 
sets up watches on specified widget attributes, and reflects those 
changes into the widget's DOM.  I'm not against something better though.

> I think another beneficial pattern for clarity of code with code-based
> attribute access would be using get()/set() pattern for code-controlled
> property access. We have discussed this before, but I think this is much
> clearer the current widget attr() that handles both gets and sets.
> watch()/get()/set() would make a clear easy-to-use pattern for
> interacting with widgets.
>
> [1]
> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/Object/watch
> [2] http://www.flapjax-lang.org/
> [3] http://ajaxian.com/archives/fin-self-updating-template-language
>
>   
Agreed.   As I said before making get()/set() the canonical interface is 
mainly backwards compatible with attr() (assuming an attr() stub to call 
get()/set()), except it will trip up code that is connecting to attr() 
depending on all property changes to go through that method.

This reminds me of Eugene's dojox.form.Manager class 
(http://www.slideshare.net/elazutkin/rad-crud) a bit. if you followed 
the pattern of gatherFormValues() then get() could have many signatures, 
like:

    get()   --> get dictionary of "all" attribute values (have to define 
what that means for widgets)
    get("disabled")   --> return value of "disabled" attribute
    get(["disabled", "checked"])   --> returns for example {disabled: 
true, checked: false}

Not sure if it's useful to get that complicated but get() with no 
arguments seems interesting as a way to serialize widgets.

Presumably set() would also take a dictionary of name/value pairs; again 
that would help with serialize/deserialize.





More information about the dojo-contributors mailing list