> Why don't you use references instead of the id's. Those are JS object which
> can be handed around as references.
> This can be done before the model has been created e.g. in the stores
> manipulateData delegate. Thats the way it should be use, I would propose.
That was my initial implementation and the task object was defined like this:
var task = {
id: 1,
description: "my first issue",
state: { id: 2, name: "Closed" } // Nothe that i'm now using a
"real" state object, not just the PK
};
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#.
The result is that "task.state" will never have a correspondence in
"states" array, so the binding of the selected item doesn't work.
I've digged deeply in the Qx sources to find this, the problem is in
qx.data.controller.MSelection.__getSelectableForModel, line 3337
if (children[i].getModel() == model) // Compare by references, so {
id: 2, name: "Closed" } == { id: 2, name: "Closed" } will always be
false
Probably the most OOPish solution will be to have object equality
support built in qx.core.Object, but i suppose this is a rather eavy
refactoring..
In conlusion, i think that using "FK like" references is a good compromise
Gian Marco Gherardi
http://gianmarco.gherardi.me
On Wed, Aug 3, 2011 at 6:00 PM, Martin Wittemann
<[email protected]> wrote:
> Hey,
>
>> when working with data from a relational database is really common to
>> have a column that refer to the primary key of another table (a
>> foreign key). Suppose, for example, to model a bug tracking system. We
>> can have a task that refer a state:
>>
>> var states = [
>> { id: 1, name: "Open" },
>> { id: 2, name: "Closed" },
>> ];
>> var task = {
>> id: 1,
>> description: "my first issue",
>> stateId: 2
>> };
>>
> Why don't you use references instead of the id's. Those are JS object which
> can be handed around as references.
> This can be done before the model has been created e.g. in the stores
> manipulateData delegate. Thats the way it should be use, I would propose.
>
>> to bind a task object structure to the UI we have to create a
>> SelectBox that holds all states objects, showing "name" field and
>> using "id" field as model. We can then bidirectionally bind the
>> selection in SelectBox to "task.stateId". To accomplish this task we
>> have to customize the controller for the SelectBox in this way:
>>
>> var stateComboBox = new qx.ui.form.SelectBox();
>> var statesController = new qx.data.controller.List(null, stateComboBox);
>> statesController.setDelegate({
>> bindItem: function(controller, item, index) {
>> controller.bindProperty("id", "model", null, item, index);
>> controller.bindProperty("name", "label",
>> controller.getLabelOptions(), item, index);
>> }
>> });
>>
>> And this works well. So the question is:
>>
>> Given that this use case is common, why not adding another optional
>> "modelPath" parameter to the constructror, to avoid using
>> IControllerDelegate? The previous code will then become:
>>
>> var stateComboBox = new qx.ui.form.SelectBox();
>> var statesController = new qx.data.controller.List(null,
>> stateComboBox, "name", "id");
>>
>> Looking at qx.data.controller.List implementation, this should be a
>> trivial and non invasive feature. I can also try to prepare a patch
>> for this.
>
> That would not be much work, I agree but I don't want to add more to the API.
> First of all, it should be as small as possible and I don't think its that
> common use case (see the description above).
>
> 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
