It seems we are settling on @NamedArgument ... anybody disagree strongly?
Steve
On 2013-10-16 11:45 AM, Richard Bair wrote:
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
