Krycek wrote: > > Sorry, forget about "widget itself" of my previous e-mail. It should be > part > of the list controller. Because It needs one list controller to each form. > That way I can have different "modelPath" for each form. And then the form > controller could use that "feature" with yours suggested > "valuePropertyChai". > > It is just my suggestion but I agree with you that something alike should > be > implemented. And if modelPath is set to null (default) it will return the > model item just like it returns today. > >
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. My 2 Euro-Cents, C. -- View this message in context: http://qooxdoo.678.n2.nabble.com/Databinding-problem-Creating-form-model-stopped-working-tp5314091p5318426.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
