Hello Christian,
panyasan wrote:
>
> Concerning the various suggestions on a simplified form binding for
> selection widgets: I am thinking of something like adding an argument to
> qx.ui.form.Form.add() like so:
>
> qx.ui.form.Form.add(IForm item, String label, (Function | AsyncValidator
> | null) validator, (String | null) name, Object options )
>
> options being a map. Options could have a valuePropertyChain, which tells
> the form-to-model binding how to find the scalar value of a form item
> value in a selection widget. So, for example,
>
> form.add(myCurrencySelectBox, "Choose Currency", null, "currency", {
> valuePropertyChain : "model.value"
> });
>
> would allow a direct, bidirectional model->form binding: whenever the
> model changes, the binding will iterate through the items by
> getModel().getValue() to find the right item(s) to select. Whenever the
> user changes the selection, the model will receive the value of the
> getModel().getValue() call on the selected item(s). This could have a
> different behavior for single-selection widgets (scalar) and
> mulit-selection widgets (array) - which would be more user-friendly. Or
> the model values are always arrays to be more consistent with the API.
>
> I think enhancement of form binding along these lines would make the life
> of developers who work with forms a lot incredibly easier and it would
> result in a lot of saved time us!
>
I think thats something we should take a look at some time. We already have
a bug about that, even its a bit more general than in your situation:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=3668
I just updated the milestone to 1.3 because i sure won't get it for 1.2 but
its a topic after the release.
panyasan wrote:
>
> Martin, do you think it would be possible to apply this patch?
>
This patch may solve your problem but I think the real problem is just
hidden with that. Is it intentional that you have a qooxdoo object stored
as model when you create the form model?
panyasan wrote:
>
> I guess the real design question at which point the "scalarization" of
> complex model data happens - at the level of the widget (List, SelectBox,
> Tree), at the level of the Form, or at the level of the Form Controller.
> The current design is, as I see it, centered on the Form Controller, where
> you can add converters with the addBindingOptions() method.
>
> In my use case, the form is constructed independently of the form
> controller, and only later connected with the controller. The way I use it
> requires that the controller doesn't know about the widgets in the form,
> it just knows the names, and form fields might be visualized as different
> widgets. In this usage, I would need the form to expose its widgets in a
> uniform way to the controller -- which is no problem with the IForm
> widgets, which all have a getValue() method. A "valuePath" at the form
> level (specified when adding the selection widget) seems to make sense to
> me, cleanly separating model data from the visual representation. But I am
> curious what databinding wizard Martin has to say on the issue.
>
If we want to fit it with the idea of all the data binding I had all the
time, there is only one place where it could be fixed and thats the
controllers. The models are only dumb data storing objects and the views
(widgets) should have no idea about the binding. Thats the case with the
list, form, tree and if possible, that should continue. But I don't have a
clear idea of how to address this issue. I need some time to think about a
good solution which combines both kinds of models. On one hand, you have the
data model which contains the data necessary to view the widget (e.g. list
item) on the other hand, you have a deputy. So maybe there has to be two
things... i don't know but be sure i come up with a good and easy to use
solution. :)
Best,
Martin
Btw. Wooohooooo, I'm a wizard. :D
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Databinding-problem-Creating-form-model-stopped-working-tp5314091p5319852.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
