Programmatic JavaFXBuilder w/o JavaFX bean properties

Will Hoover java.whoover at
Fri May 25 07:22:30 PDT 2012

The first part of my last response only addresses 1-way binding from the
JavaFX property to the POJO- not from the POJO back to the JavaFX property. 


However, the second part of my last response does address what you are
talking about. You would be able to add a binding provider that would know
how to handle changes made to your POJO and propagate them back to
corresponding JavaFX properties. It could be an application, module, or
model specific provider that would implement methods that would update the
JavaFX properties. Of course, it would "no longer be a POJO" if you try to
create providers yourself, but if you're using something like JPA entities
you get that for free... They are still POJOs. They just have JPA
annotations or a corresponding ORM mapping file. 


By adding a provider capability it would allow for a multitude of
possibilities. You could even use a Spring binding provider that could
utilize Springs AOP/DI mechanisms. 


From: John McDonnell [mailto:mcdonnell.john at] 
Sent: Friday, May 25, 2012 8:54 AM
To: Will Hoover
Cc: Richard Bair; openjfx-dev at
Subject: Re: Programmatic JavaFXBuilder w/o JavaFX bean properties


I would love not to have to replicate my POJO's as JavaFx beans, but how
will the Java FX property get updated when a standard POJO doesnt have a
mechanism (that I know of, apart from PropertyChangeSupport??) to listen to
changes made to properties, and update the JavaFX property?


Surely adding something like PCS, would mean that the bean isnt a POJO




On 25 May 2012 13:20, Will Hoover <java.whoover at> wrote:

I was thinking that we could use something like the existing
Bindings.bindBidirectional(property1, property2), but utilize what FXML has
done under the hood...

Then we could do something like Bindings.bind(person, "",
myJavaFxControlProperty). Where the specified JavaFX Property would be
systematically bound (one-way) from the specified Property to the passed
POJO path. This capability would at least give us a way to bind without
creating a lot of boiler-plate code that is currently needed (i.e. JavaFX
properties for all the domain model POJO properties used within an
application). I noticed that most of the implementation for this currently
exists within various components used by the FXMLLoader class. So, I would
suspect that it would be trivial to implement?

An even better solution would be to introduce an extension provider where
other java specifications like JPA could play a role in the binding process.
For example, JPA provides a mechanism to annotate an @Entity with
@PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpdate,
and @PostLoad which allows a JPA binding provider implementation to capture
changes to an @Entity POJO. Now, we could allow bi-directional binding using
JavaFX control properties and JPA @Entity fields... Every time an @Entity
field changes it can be reflected in the JavaFX control. Maybe something
like Bindings.addProvider(myJpaToJavaFxBindingProvider) and
Bindings.bindBidirectional(jpaAnnotatedPerson, "",

-----Original Message-----
From: Richard Bair [mailto:richard.bair at]
Sent: Thursday, May 24, 2012 9:30 PM
To: Will Hoover
Cc: openjfx-dev at
Subject: Re: Programmatic JavaFXBuilder w/o JavaFX bean properties

I'm not sure what you have in mind?

On May 24, 2012, at 11:07 AM, Will Hoover <java.whoover at> wrote:

> Is there a way to programmatically use some of the automatic POJO binding
> capabilities of the JavaFXBuilder class?
> I know we can use JavaFX bean properties using Bindings like
> , but who wants
> to create a property for all the fields used in an domain entity/model
> class?


More information about the openjfx-dev mailing list