Tom Eugelink tbee at
Mon Dec 19 23:14:37 PST 2011

On 2011-12-19 10:15, Michael Heinrichs wrote:
> this works only for bidirectional bindings. If you do a unidirectional bind between a Property p and an ObservableValue v, then v may very well be read only.


> I was thinking about such a sync-back functionality for bidirectional bindings. But actually I am not sure, what we want to do in such cases. Do we want to set a default value, throw an exception, try to sync back or maybe do something else? Is there a one-size-fits-all solution possible? Maybe best would be a solution, that allows all kinds of behaviors easily, but I have no idea how to achieve that.

The (IMHO) defacto standard sync library, jGoodies, does such a sync back. If one visualizes bindings as "wiring up a model", then logically it means that both sides of the wire are identical. jGoodies AFAIK does not have a readonly mode, both sides are always identical, the only thing that can be tuned is the initial sync when making a binding: A->B or B->A.

Assuming that you mean "not externally modifyable" by read only, but the value can change via internal means, then two way binding still is a good approach. Initially you would do a R->A, thus setting A with R's value. Then if A changes, you would try a A -> R, that would fail and next R->A is done. A cannot change, because it is bound to a read only value. Correct behavior IMHO. If R were to change internally, R->A would still work fine.

But maybe you can describe what scenario's you see?

I had hoped JavaFX's properties would be usable in business models as well, but their event setup do not allow them to act like business model properties, where setting a value may result in an exception (IllegalArgumentException) because it is not within the allowed bounds or something. For example trying to set a null or so. Naturally one could skip throwing the exception and simply not set the value, a sync back would then correct it, but there would be no error in that case (so the user doesn't know what is wrong). That would mean the error handling has to be added as a staffing function.


More information about the openjfx-dev mailing list