Making JavaFX Development Faster

[Richard Bair]

This is a problem I've had with client Java since I joined the Swing team in 2004. The basic issue is that POJO's rule the day, but if you want to do binding on a POJO, how do you do it? You really have three options:

	- Use observable POJOs (either using JavaBean's property change listeners, or JavaFX property objects)
	- Wrap a POJO
	- Use dynamic code mangling

I have at various times been lobbied for each of the above approaches. I suspect that the first and last approaches are the most pragmatic, although the dynamic code mangling solution, because it introduces black magic, is also the most unsettling. If the implementation was rock solid and always "just worked" as one would expect, then it would be an acceptable approach (but not something you'd likely see in JavaSE, which tries to avoid black magic).

So for example:

MyObject obj = new MyObject();
obj = BlackMagic.makeObservable(obj);

obj would now magically have old-school PropertyChangeListenter methods added to it, etc, such that you could use the javafx.beans adapters.

However, the javafx beans package and collections and such are part of the "base" module -- ie: they could be separated from the rest of javafx and safely used on the server side or elsewhere. Why not just use properties and such on the server side definition of classes? Or are those classes being auto-generated and thus not taking observable properties into account?

Richard

On Oct 22, 2012, at 3:30 AM, Werner Lehmann wrote:

> 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