Making JavaFX Development Faster
lehmann at media-interactive.de
Mon Oct 22 03:30:38 PDT 2012
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).
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.
More information about the openjfx-dev