Making JavaFX Development Faster

[Werner Lehmann]

Basically FX likes to have observable properties, and POJOs (domain 
beans) should not have an FX dependency. Sounds like a contradiction.

Without changing the POJOS we can only wrap or subclass them.

A wrapper would delegate all getters and setters and introduce 
observable properties. The property objects must use the wrapped POJOs 
fields to keep their values instead of having their own value field. One 
problem is how to know when a POJO setter is called directly?

A subclass would add the observable properties directly. It could also 
override the setters, thus triggering the property invalidations. The 
problem here is that data has to be copied from the POJO to an instance 
of the POJO subclass (and possibly also the other way).

A code generator can be built for either approach. It would FXify a set 
of provided POJOs. I am not sure if that is really desirable though. I 
really don't want to deal with a "shadow" class for each POJO class.

FWIW, it might also be possible to use a java.lang.Proxy. In this case 
we still need an interface for each POJO (consisting of getters, 
setters, observable properties). The proxy would act like an FX view to 
the POJO. It can intercept the setter calls and trigger invalidations. 
Still there is the requirement of having POJO specific interfaces 
(another code generator here).

Werner

On 21.10.2012 19:16, Mark Fortner wrote:
> The article that Will pointed out was interesting.  However, the developer
> would still end up having to write code to make their POJOs or POJO
> collections observable.  It would be nice if there was a "dynamic proxy"
> that automagically made any class you sent it observable.  Not sure how
> doable that is -- just thinking off the top of my head.
>
> The one thing that you would need to avoid is making your POJO have any
> JavaFX dependencies.
>
> On the issue of RAD tooling, it sounds like the Griffon team is making some
> progress with respect to making JavaFX easier.  I'm not sure how well
> Griffon's Service and Controller interfaces map to JavaFX's Controller.
>
> Cheers,
>
> Mark