JavaBeanPropertyAdapter

Michael Heinrichs michael.heinrichs at oracle.com
Tue Dec 20 01:56:48 PST 2011


Hi Tom,

I think what you are after is what we internally call data-binding. Way back in the beginning of the JavaFX 2.0 project, we split the domain of bindings into property-bindings and data-bindings. 

Property-bindings are pretty much a port of JavaFX 1 bindings. The main goal is to bind properties to any kind of expression. The vision is to allow really huge numbers of bindings and very complex expressions in an application. Naturally the main requirements are flexibility when it comes to defining the expressions, low memory footprint and high performance.

The main use case for data-bindings is to bind the UI to the business model. The set of requirements is very different. The bindings themselves are usually simple, you just want to copy one value elsewhere, no calculation required. But the logic around them is much more complex:. you want to define constraints, often you do not want the values to be synced immediately, but only after the user presses a "Save"-button. Maybe data-bindings also need to support asynchronous synchronization, if you want to push the changes to the server and the server might reject certain values. Usually you do not only want to bind single properties, but whole sets of properties. Maybe you also need support for transactions and the ability to rollback a set of changes, if one of the changes fails, ...

The requirements are quite different and partially contradict each other. Thus we split them and defined two different kind of bindings. The Binding API in the core libraries deals with property-bindings only. There is certainly a grey area. With support for POJOs, especially with binding-support for POJOs, we enter this grey area and have to be careful to draw a clear line. 

The long term vision is to implement data-bindings on top of property-bindings. I do not know what the current state of data-bindings is, maybe somebody else can answer that.

- Michael



On 20.12.2011, at 08:14, Tom Eugelink wrote:

> 
> 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.
> 
> True.
> 
>> 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.
> http://tbeernot.wordpress.com/2011/04/02/javafx-2-0-ea-binding/
> 
> Tom
> 
> 
> 



More information about the openjfx-dev mailing list