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

Rahul Akolkar rahul.akolkar at gmail.com
Sun Mar 13 00:39:15 EST 2011


Hi Christophe,

Inline.

2011/3/12 Christophe Jolif <cjolif at gmail.com>:
> Rahul,
>
> I think this would be a great addition to dojo to be able to easily bind
> data model properties to widget properties in a similar fashion other
> frameworks are doing and so all of this look really promising to me.
<snip/>

Cool, thanks.


> However
> I see that for iteration on bindings you are relying on a "repeater" widget.
> This will work fine for "form" like applications where you are iterating
> over each of data item outside of the widget itself
<snap/>

Yup, couple of repeat related background comments:
 * Repeat is for generating data-bound user interfaces over
collections in data (i.e. arrays) where each item may produce an
arbitray data-bound UI as defined by a parameterized and
application-specified template. This is most useful in form-based apps
driven to support CRUD style operations.
 * I'm looking into making repeat more transparent -- idea is there
shouldn't be any need to use a specific "repeater" widget if there is
a suitable container available. Any container widget that binds to a
collection in data should be able to function like a repeat i.e. add
appropriate children based on collection (data-bound TabContainer, for
example).


> but what about more
> complex widgets that directly take the full data set either as a list or a
> hierarchy as input and need to bind specific part of the widget to specific
> model properties?
<snip/>

Yup, logical next step :-) I'll answer this below, but let me point
out here that one of the benefits of introducing a client side model
as this work does is to provide means for data binding concerns of all
widgets (simple or complex) to be addressed in a consistent manner,
while providing the connection to the store(s).

The existing trend in Dojo is for most of these complex widgets to
provide data store support in their own classes. Going from a widget
to a store is reasonable for simple applicatons, but more generally
this approach has some failings:
 * There is potential for reuse that gets ignored as each widget /
module reinvents some parts of the data wheel.
 * There is potential for differential treatment of data concerns
across widgets (inconsistencies).
 * These complex widgets have no means to easily talk to each other
(case in point, see loan form demo in the patch on #12314, I'd like
that chart to have same data binding capability as the form dijits so
we don't have to rely on the controller aspects to keep it in sync).


> As far as I can see your patch does not address directly
> this use-case, however maybe the data model and the binding mechanism you
> are proposing is flexible enough for other developers to leverage it on more
> complex widgets?
<snap/>

Yes, the model is designed to be quite generic. The model class has no
dependencies other than dojo.Stateful (a couple of changes were made
based on feedback here that further ensured that). Getting the model
to work with complex widgets won't be much different to simple ones,
but has the caveat that the complex widgets need to implement Stateful
correctly in this context (if they don't already). Clearly, the patch
doesn't contain such for any complex widgets because it focuses on
data binding for dijit -- which is the most urgent bit AFAIAC.


> I must admit I don't have time to dig into this to check if
> that is possible but I think it would be useful at some point to extend this
> mechanism to other widgets and thus we should make sure to go into a path
> that will allow that later on.
>
<snip/>

Absolutely, having other widgets gain the ability to talk to the same
stateful model is important (and useful). I have had a conversation or
two with some dojox.mobile folks and another with the some grid folks
about this. For example, if I want to add a mobile version of my app,
I should be able to reuse much of my client-side stateful model code,
data constraints and binding mechanism (and we can, with this work).


> Examples:
> -a chart might want to bind its y-values to field revenue in the data items
> and its bar colors to the field profit.
> -a grid might want to bind columns values to particular properties in a data
> item
>
<snap/>

Indeed, good examples. We (you, me, others interested) should talk
about charts and binding them to stateful models in more detail at
some point.


>  Is that something you foresee feasible with your model later on?
<snip/>

Mais oui, monsieur :-)

-Rahul


> Thanks,
> --
> Christophe
>
<snap/>


More information about the dojo-contributors mailing list