Support for JavaFX properties?

[Jacek Furmankiewicz]

Hi are there any plans to add support for JavaFX properties in @Getter, @Setter and @Data?

http://docs.oracle.com/javase/8/javafx/properties-binding-tutorial/binding.htm#JFXBD107

That is a lot of boilerplate to enter....

 
class Bill {
 
    // Define a variable to store the property
    private DoubleProperty amountDue = new SimpleDoubleProperty();
 
    // Define a getter for the property's value
    public final double getAmountDue(){return amountDue.get();}
 
    // Define a setter for the property's value
    public final void setAmountDue(double value){amountDue.set(value);}
 
     // Define a getter for the property itself
    public DoubleProperty amountDueProperty() {return amountDue;}
 
}

[Jacek Furmankiewicz]

This would be very easy to support in a simple sane way:

All the logic for @Getter, @Data and @Value would just need to detect that if it is dealing with an object of type javax.beans.property.Property

then avoid using the "get" prefix for the getter and add "Property" suffix instead.

In this case the code would be just

@Value
class Bill {
    private final DoubleProperty amountDue = new SimpleDoubleProperty();
}

which could generate the method

.

public DoubleProperty amountDueProperty() {return amountDue;}

It would not give us the JavaBean-style getter/setter for underlying value, but from what I read from JavaFX developers
they often just use the raw Property fields in their POJOs and bypass the JavaBean standard altogether
since it unnecessary and duplicate in this case.

Hope this could be a simple enhancement that could make JavaFX a lot more pleasant to develop.

[Jacek Furmankiewicz]

Thanks to a knowledgeable poster on reddit, I realized this is possible already with the experimental fluent @Accessors annotation:

http://www.reddit.com/r/java/comments/2vrtyl/javafx_propertiesa_clear_example_of_why_java/cokmznp

It would still be great though to get the full JavaBeans specs generated from this if possible.

[Reinier Zwitserloot]

Sure, but as we don't use it, we'd have to go solely on the work of our users to tell us _exactly_ what we should generate here, and triggered by what. To wit:

* Have a special annotation, just make fields of type 'double' and such, and we map 'double' onto DoubleProperty. We'd need a complete list of types to map, and note that we can only go by the actual type of the field, not of the object that it is pointing at.

* OR just automatically have getter, setter, data, value, etc key off of the javafx special property classes such as DoubleProperty. We'd need a complete list of all such properties, what the types are that its setter/getter should take, and we'd also need to know what to do in the face of getter, setter, data, and value. For example, should they be made final even on a @Data class (obviously that'd happen on a @Value class). Should we still generate the setter with a @Value class? Should we just generate a warning that @Value and javafx property fields don't make any sense? Should we try to turn the property into a read-only one? Is there even such a thing?

* Is there any chance that this change, if we go with option 2, is going to peeve off users? We WILL be changing, backwards incompatibly, how @Getter etc work on javafx properties.

* Are there ANY feasible scenarios where the planned change (generate getter, setter that deref the property, and add another method that returns the property itself) is NOT the appropriate code to generate? Does it ever happen that you have a property field where the property _ITSELF_ (as in, the xProperty object itself) is a settable/gettable entity, and/or should not be exposed other than via the entire property object? I'm guessing they are rare but not unthinkable, which means the first option (special annotation) has the preference.

 --Reinier Zwitserloot

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jacek Furmankiewicz]

Hi Reiner, thank you for answering.

I don't think we should wrap a double into something like a SimpleDoubleProperty automatically. Users may want to customize the behavior of the bindable property and we should not remove it from them//

I think the easiest way with the least impact on existing code would be to create a new annotation

@FXVal

which would basically take a POJO with a set of property objects, automatically expose it as a property + auto-generate the getter/setters

so let's say something like

@FXVal
class Person {
     private StringProperty firstName = new SimpleStringProperty();
     private StringProperty lastName = new SimpleStringProperty();
     private IntegerProperty age = new SimpleIntegerProperty();
}

would get automatically expanded to

class Person {
     private final StringProperty firstName = new SimpleStringProperty();
     private final StringProperty lastName = new SimpleStringProperty();
     private final IntegerProperty age = new SimpleIntegerProperty();

     // expose property objects in naming format JavaFX expects for data binding
     public StringProperty firstNameProperty() {return firstName;}
     public StringProperty lastNameProperty() {return lastName;}
     public StringProperty ageProperty() {return age;}


    // expose traditional getters/setters to implement traditional JavaBeans spec
    public void setFirstName(String firstName) {this.firstName.set(firstName);}
    public String getFirstName() {return this.firstName.get()}

    public void setLastName(String lastName) {this.lastName.set(lastName);}
    public String getLastName() {return this.lastName.get()}

    public void setAge(Integer age) {this.age.set(age);}
    public Integer getAge() {return this.age.get();}  
}

that would probably go a long way to handling 99% of the use cases with minimal impact on existing code and any changes to backwards compatibility.

JavaFX bindable beans are really a different type of beast and a major hack by Oracle IMHO to get around the lack of properties in Java,
so I think it is OK to create a separate annotation just for them.

Let me know what you think

Jacek

[Jacek Furmankiewicz]

Sorry, that should have been

 public IntegerProperty ageProperty() {return age;}


not StringProperty, sorry about that

[Lenny Primak]

I would love to see something like JavaFX properties in Lombok

This gets my vote

[Mr. H.]

There ist a Simple way to determine the returntype for the Getter and the Parametertype for the Setter. Every JavaFXPropertytype implements

Property<T> use T as the Type you are looking for.