Making JavaFX Development Faster (original) (raw)
Werner Lehmann lehmann at media-interactive.de
Mon Oct 22 03:30:38 PDT 2012
- Previous message: Making JavaFX Development Faster
- Next message: Making JavaFX Development Faster
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Making JavaFX Development Faster
- Next message: Making JavaFX Development Faster
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]