[dojo-contributors] Presenting the data binding kitchen sink ...

ben hockey neonstalwart at gmail.com
Thu Mar 17 13:32:54 EDT 2011


i've just taken a look at your latest patch for #12314.

first something not completely technical...
my personal preference would be to see the recursive model pulled out 
into a class that was a sibling to dojo.Stateful.  you mentioned in a 
previous post on another thread that this may be possible but you didn't 
see much use for it.  of course, this model provides a way to cleanly 
separate the view from the model and with this separation taken to the 
extreme, it should be possible to not even use dijit widgets for these 
views but still use the model with an alternative ui.  in that case, it 
would be best to have StatefulModel avoid any dependencies on dijit 
(including DataBindingMixin).  it seems that the only reason for the 
dependency on dijit is because dijit is a consumer of this model but imo 
that should not imply that the model has a dependency on any part of dijit.

in order to function, the only true dependency as the code stands right 
now is dojo.Stateful.  the dependency on "dijit" is only so that you can 
attach to the dijit global and the dependency on 
"dijit/_DataBindingMixin" is only to silently extend dijit._WidgetBase.  
based on comments from the touch/gesture thread i get the impression 
that this kind of silent activation might not be desirable but i'll 
leave that up to bill to decide if it's good or bad.  my desire is 
simply to be able to have the model without the dependency on dijit - a 
dijit-specific subclass of the model could still trigger the silent 
activation if that was acceptable or user's could explicitly add a 
dependency on DataBindingMixin.

with the move towards using more specific dependencies in 1.7, dojo 
would be able to offer a very powerful yet cheap (in bytes) solution for 
the model portion of an application.  combined with dojo.store dojo can 
provide complete support for models with dependencies limited to the 
actual classes themselves and dojo base (or possibly less).  surely 
there is at least some marketing value in that - use whatever ui you 
already have and use dojo for your model and it won't cost you much (in 

i'm open to other opinions regarding this but that's mine fwiw.

now, onto the more technical comments...
     - it looks like bindModelToView never gets used?  is that the 
case?  if so, i'm sure you're not opposed to getting rid of it.
     - part of my thought with introducing a general bind function was 
to remove the explicit bindXXX functions.
         // no more bindRequired, bindReadOnly, bindRelevant, bindValid
         bind: function (source, targetProp, func, bindOnlyIfUnequal) {
             return this.bindProperties(source, 'value', this, 
targetProp, func, bindOnlyIfUnequal);
     as you've mentioned previously, these properties are not a closed 
set and this at least provides some sugar for binding to the value of a 
source which is probably the most common property to bind to.  btw, 
using my implementation above, your current implementation of bind would 
be the equivalent of calling:
         bind(source, 'value', func, true)

     - startup should probably call this.inherited
     - _updateBinding - observation: once all of this data binding work 
becomes widely adopted i can see us possibly coming up with a way to 
define which properties we want to watch on the model and a convention 
for which handlers to use for those.  something like the _setFooAttr stuff.

again, i only looked at these 2 files but i took some more time with the 
demos this time around and i'm looking forward to seeing this patch land 
in trunk some time soon.



On 3/11/2011 6:11 PM, Rahul Akolkar wrote:
> Hi all,
> A new day brings programmatic data binding support (part of Bill&
> Ben's feedback), the ability to disconnect the data binding contextual
> hierarchy from the DOM (related to Ben's feedback) and some other
> improvements. I have:
>   * Incorporated most feedback from Bill and Ben in other thread (thanks again).
>   * Added support for programmatic data bindings and the ability to
> provide a ref as a model node object.
>   * Added support for specifying widget-relative refs for data bindings
> (more in item 2d below).
>   * Added a simple programmatic example to the tests and a kitchen sink
> example (probably won't be common to see a mix of this sort in apps,
> but its good to know and test that data bindings can work in harmony
> regardless of how they are specified).
>   * Reworked tests to use new parser syntax, leaving one suitably
> labeled test in old format for kicks as well as for regression
> testing.
> To illustrate the data binding feature in dijit, I've pasted some
> samples from the test cases (these are available in the refreshed
> patch on #12314) in this message:
> 1. -- Programmatic data binding --
> a. Creation or page load time, simple example
>    // Function below shows programmatic creation
>    // of data-bound dijits - "mainContent" is ID of parent div
>    function addBoundDijits(){
>      var model = dijit.newStatefulModel({ data: { first: "John", last: "Doe" }});
>      var fn = new dijit.form.TextBox({id: "fn", ref: model.first});
>      fn.placeAt(dojo.byId("mainContent"));
>      fn.startup();
>      var ln = new dijit.form.TextBox({id: "ln", ref: model.last});
>      ln.placeAt(dojo.byId("mainContent"));
>      ln.startup();
>    }
> b. Manipulating refs later, from my "toggle" example (grep patch for
> "simple-programmatic.html", the below happens when one hits the toggle
> button):
>    // Function below shows programmatic update
>    // of data-bound dijit refs
>    function toggleRefs(){
>      var fn = dijit.byId("fn"), ln = dijit.byId("ln");
>      var ref = fn.get("ref");
>      fn.set("ref", ln.get("ref"));
>      ln.set("ref", ref);
>    }
> 2. -- Declarative data binding (not showing models here) --
> a. Direct data binds (or absolute references to model nodes):
>    <input data-dojo-type="dijit.form.TextBox" id="serialInput"
>           data-dojo-props="ref: model.SerialNumber"></input>
> b. Relative data binds (see<input>s, which are relative to parent):
>    <div data-dojo-type="dijit.mvc.Group" data-dojo-props="ref: model">
>      <div class="row">
>        <label for="serialInput">Order #:</label>
>        <input data-dojo-type="dijit.form.TextBox" id="serialInput"
>               data-dojo-props="ref: 'Serial' "></input>
>      </div>
>      <div class="row">
>        <label for="nameInput">Name:</label>
>        <input data-dojo-type="dijit.form.TextBox" id="nameInput"
>               data-dojo-props="ref: 'Name' "></input>
>      </div>
>    </div>
> c. Breaking out of enclosing widget's nested binding context if it
> makes sense (serialInput has relative ref, name breaks out --
> fictitious example):
>    <div data-dojo-type="dijit.mvc.Group" data-dojo-props="ref: model">
>      <div class="row">
>        <label for="serialInput">Order #:</label>
>        <input data-dojo-type="dijit.form.TextBox" id="serialInput"
>               data-dojo-props="ref: 'Serial' "></input>
>      </div>
>      <div class="row">
>        <label for="nameInput">Name:</label>
>        <input data-dojo-type="dijit.form.TextBox" id="nameInput"
>               data-dojo-props="ref: otherModel.Name"></input>
>      </div>
>    </div>
> d. Anchoring data binding context to another widget by ID where the
> enclosing widget may not have the right data binding context or the
> widget may not be stationary in the DOM (example binds textbox to the
> 'SerialNumber' model node as specified, relative to the data binding
> of the widget with ID "orderGroup"):
>    <input data-dojo-type="dijit.form.TextBox" id="serialInput"
>           data-dojo-props="ref: 'widget:orderGroup.SerialNumber'"></input>
> Ofcourse, all of these flavors work together in concert if need be.
> I think the code is ready for another look, I'd appreciate more
> feedback. Have at it ;-)
> -Rahul
> _______________________________________________
> 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