Ya that works too.
> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova <eva.krejcir...@oracle.com> wrote: > > Good point! > In FX sources, we already use the @Default annotation which was used by > annotation processor when generating the builders. Because of this, it has > source retention policy, so it cannot be used by FXMLLoader. I was thinking > about promoting this to runtime annotation but maybe your solution is better. > > We should solve this for FX8 otherwise the FXMLLoader will behave differently > from how the generated builders behaved. > > Eva > >> On 16.10.2013 17:24, Tom Schindl wrote: >> One thing that just came to my mind is that maybe also need a way to >> define the default value to be used, with a builder I could e.g. define >> that the default for fields are different from their real native default. >> >> class MyBuilder { >> private boolean a = true; >> private int x = -1; >> private Insets i = new Insets(10); >> } >> >> If we want to have a full replacement for builders the annotation must >> have the possibility define this (in future). >> >> public @interface NamedArgument { >> String value(); >> String defaultValue(); >> Class<Converter> converterClass(); >> } >> >> If no converterClass is given we'd have to do our best to auto-convert >> the String. I don't want to say that we should implement the default >> value definition in FX8 but it would feel more natural with an >> annotation per argument. >> >> Tom >> >>> On 16.10.13 17:12, Tom Schindl wrote: >>> To me the JavaBean solution with one annotation looks error prone, does >>> anybody know why they did not use an annotation per field? >>> >>> Tom >>> >>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>> consistency? I realize that we can't have the reference. >>>> >>>> Steve >>>> >>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>> created unwanted (and circular) module dependencies. Seems like it >>>>> needs to be in the "base" module then, right? >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Richard Bair wrote: >>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>> and should be considered part of our javafx.beans API. >>>>>> >>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>> <tom.schi...@bestsolution.at> wrote: >>>>>>> >>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>> have a way to create classes without default constructors. Back >>>>>>>> then we >>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>> annotation will look like and I could use some help with this. >>>>>>>> >>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>> >>>>>>>> We have two options: >>>>>>>> >>>>>>>> 1. Annotate the whole constructor: >>>>>>>> e.g. >>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>> >>>>>>>> 2. Annotate the arguments: >>>>>>>> e.g. >>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>> >>>>>>>> >>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>> >>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>> by javax.inject) >>>>>>> >>>>>>> Tom >