Hi Vincent,
Martin (our data-binding guru) is still out of office because of his
broken hand so I will try to answer your questions. The details how to
actually change qooxdoo's data binding will have to wait until he's back.
> Hi all,
> I'm diving right now into Qooxdoo data binding; really nice
> implementation ! I've got some questions though.
>
> I'm trying to implement a bi-directional binding between a textfield and
> some value object that has a "value" property with an associated
> "changeValue" event. So I use a qx.data.controller.Object around my
> value object and bind the textfield bi-directionally as a target :
> modelController.addTarget(textField, "value", "value", true);
> So far, so good.
> The problem comes from the fact that qx.ui.form.TextField doesn't allow
> for null value (only empty string, right ?), and my value object does...
> Is there any reasoning behind preventing handling textfield null value
> as empty string behind the scene, cause it seems to me a quite common
> use-case.
>
> Anyway, I then leveraged binding options and reversOptions to add a
> "converter" that transforms null into "" and vice versa. Now the problem
> comes from the fact that the qx.ui.form.TextField value is not a real
> Qooxdoo property. It only has accessors and event. Then, at runtime it
> complains that there is no "resetValue()" method on textfield when my
> value object "value" property is null. I checked the source and the
> converter functions are not used when testing for null value and
> triggering the reset property. So the final workaround was to add a
> resetValue method (not very clean...) :
> textField["resetValue"] = function() {textField.setValue("");}
>
> What would make sense to me is :
> - support target properties that are not actual Qooxdoo properties, i.e.
> only have accessors (and even only a setter if it's a one-way binding
> ?). This would imply testing for the presence of all the derived
> property methods like "resetXXX" before execution.
>
I think this is a very good point. There are places like the text field
where properties cannot be used. We should check for the reset method
and only call it if it is available. Can you please open a bug for this
and assign it to Martin?
> - use the converter functions, if any, before testing for model "null"
> property value and then triggering the "resetXXX" method.
>
This looks like a real bug to me. The converter should always be called
first. Again, please open a bug and assign it to Martin.
> - allow for null values in qx.ui.form.AbstractField derived classes that
> should be handled as the empty string.
>
Right, this is even a violation of the "qx.ui.form.IStringForm"
interface, which explicitly allows "null" values in the API
documentation. Again: Bug -> Martin :-)
> Would it make sense ?
>
>
Absolutely. We are still fleshing out the data binding code and user
feedback like yours is really appreciated. As I said it may take a while
until it gets fixed but I think all three points are valid and will be
addressed.
Best Fabian
--
Fabian Jakobs
JavaScript Framework Developer
1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[email protected]
Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas
Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver
Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
