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

Reply via email to