[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    JavaBeanPropertyAdapter
From:       michael.heinrichs () oracle ! com (Michael Heinrichs)
Date:       2011-12-20 9:56:48
Message-ID: 524C6C1B-7E42-4973-88F4-07768BCBEEA2 () oracle ! com
[Download RAW message or body]

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
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]