See my comments above.
On Thu, Sep 8, 2011 at 7:51 AM, Martin Wittemann
<[email protected]>wrote:
> 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)
>
but our code gets smaller. I have no project I haven't done that, I don't
know about the others but it's pretty common for me doing that. That's not
something I comfortable rewriting every time.
> - The API gets harder to understand (difference between "modelPath" and
> "model" property e.g.)
>
the same difference between "label" and "labelPath", so I guess we should
remove labelPath as well.
> - Binding the model may be common for select boxes but not for other
> widgets so I guess the 90% is not the reality
>
I would use it in the tree, for example. That's how I'm using the tree
widget, that's why some while ago I asked to the tree widget to be an IForm
class. Since it is now, it should act like a multiselected List in that
regard.
> - 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
>
See above.
> - 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.
>
It shouldn't be. If I can do the same thing without knowing how binding
works isn't it better? It's a common task and should be easier to do this
kind of stuff. Without setting delegates and such.
> - 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");
>
>
ListController is the only one that supports c.bindProperty("m", "model",
null, item, id);, right? For consistences reasons I think the other
controller should have it too.
>
> 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]> 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
>>
>>
>>
>> On Thu, Aug 4, 2011 at 8:56 AM, Martin Wittemann
>> <[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]
>> > 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]
>> 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]
> 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
>
>
------------------------------------------------------------------------------
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
