Hey,
here are my thoughts about that topic.
Pros:
- It would be easier to get the task done if you need a custom model path
binding because no delegate is needed.
Cons:
- The API gets bigger (need to add modelPath and modelOptions)
- The API gets harder to understand (difference between "modelPath" and "model"
property e.g.)
- Binding the model may be common for select boxes but not for other widgets so
I guess the 90% is not the reality
- We need to keep the API consistent to the tree controller which needs to have
the same new properties which sure are not as necessary as for the list
controller
- It's an advanced feature where you have to understand some details how the
binding works. With that knowledge, I thinks its ok to use a delegate.
- The current API is just another way of defining all the stuff and can be
written in a compact form as well:
var list = new qx.ui.form.List();
this.getRoot().add(list);
var model = qx.data.marshal.Json.createModel(
[{l: "a", m: 1}, {l: "b", m: 2}]
);
var c = new qx.data.controller.List(null, list);
c.setDelegate({bindItem: function(c, item, id) {
c.bindProperty("l", "label", null, item, id);
c.bindProperty("m", "model", null, item, id);
}});
c.setModel(model);
var l = new qx.ui.basic.Label();
this.getRoot().add(l, {left: 120});
c.bind("selection[0]", l, "value");
I guess you can already see the direction I'm thinking... I would rather keep
the current way.
Regards,
Martin
Am 23.08.2011 um 03:13 schrieb Guilherme Aiolfi:
Why don't introduce the modelPath property and if it is not set, use the
current, as it is, behavior?
90% of us (I guessing here, but considering how many times that has been asked
for or asked how to work around it) use the selectable widgets to return a
value.
I don't know how you create apps or how you organize your models or even if you
create apps at all.
For me, those little things take all the fun of using qooxdoo. That was one of
the reason why I tried creating another layer above qooxdoo, to abstract those
little annoyances.
But that takes so much more time, effort and energy than just be there, built
in.
Martin, since you are the architect, I'm asking you to reconsider it.
On Thu, Aug 4, 2011 at 9:07 AM, Gian Marco Gherardi
<[email protected]<mailto:[email protected]>> wrote:
Thanks for taking time to answer my question.
Hmm yes this can be a nice solution if "states" array indexes
correspond to "id" value.
However i'm trying to setup UI just using databinding code and try to
avoid extra code to setup values on ui controls.
Gian Marco Gherardi
http://gianmarco.gherardi.me<http://gianmarco.gherardi.me/>
On Thu, Aug 4, 2011 at 8:56 AM, Martin Wittemann
<[email protected]<mailto:[email protected]>> wrote:
> Hey,
>> However this way the binding of the selected item doesn't work. The
>> cause is that the "state" object instance from the "task" and the
>> "state" object instances in the "states" array are different
>> instances, and Javascript does not have the concept of object equality
>> like Java or C#.
> If you define the objects that way, they are different and then the selection
> does not work. But why not define the objects like you described in the first
> place and then connect them as soon as you have the model objects?
> Here is a little example:
> http://tinyurl.com/3zxgok4
>
> Regards,
> Martin
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]<mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
qooxdoo-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
qooxdoo-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
