Hi, Yepp, I'll see what I can do :) IMO one challenge here is that JavaFX has its own property pattern ("private IntegerProperty foo;" instead of "private int foo;"). Putting constraint annotations to such a property won't help as of today (since there is no ConstraintValidator<Size, IntegerProperty>), but I think there are solutions for this. Another problem I see with GUI validation is that one typically wants to validate form values before putting them into the model. This works fine for property-level constraints (using Validator#validateValue()), but we have nothing to offer for class-level constraints here. In case anyone has some ideas or any other input on that subject, please let me know. --Gunnar 2012/6/28 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;:

2012/6/29 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: I guess things like IntegerProperty should be rather stable, but probably users can also create custom property types. Personally, I find the option of adding support for types of specific APIs/frameworks to BV not really appealing. Maybe another API than JavaFX appears tomorrow? I could imagine to make BV extensible in that respect, e.g. by providing an SPI for hooking in some sort of adapter which is used by BV to retrieve values from given models. JavaFX then could provide an implementation of this SPI based on its property model. BV would not use reflection to operate on fields and methods and so on but rather use the SPI to walk over the type hierarchy (the default implementation of course would be the behavior as of today). Another implementation could be used to place and validate constraints on JSON/map-like structures (e.g. when working with MongoDB etc.); Constraints would have to be declared via an API/XML but not annotations in that case. I'm not really sure. AFAICS the form/controller class would have members of types such as Label, TextField etc, while the a validator for a class level constraint of the model would operate on the bean's attribute types. One could think about creating a second validator for the form types. But I'm not really a JavaFX expert :)

2012/7/1 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: Do you have some more details on that? Today BV is focused on actual Java types adhering to the JavaBeans convention (types with getters/setters), but there are use cases where one may have another type model but still would like to use the BV validation approach. My thinking was to provide an SPI which allows to customize the way BV interacts with type models. This SPI would establish an abstract type model used by the BV runtime. This model would know about "types", "properties" and so on, but these wouldn't necessarily have to be actual Java types with bean properties. The default implementation of course would be based on JavaBeans as today, but one could plug-in implementations based on other models, too. One example is a dynamic model like DynaBeans [1] (or e.g. dynamic EMF models [2]). Here "types" are defined at run-time like this: DynaProperty[] props = new DynaProperty[]{ new DynaProperty("address", Map.class), new DynaProperty("lastName", String.class) }; BasicDynaClass employeeType = new BasicDynaClass("employee", null, props); DynaBean employee = employeeType.newInstance(); employee.set("address", new HashMap()); employee.set("lastName", "Flintstone"); As of today, you can't apply constraints to the "employee" type, though, as it is no JavaBean. In such a case constraints could e.g. be declared using an API (example based on HV's constraint API): ConstraintMapping mapping = new ConstraintMapping(); mapping.type( new DynaBeansTypeIdentifier ( employeeType ) ) .property( "address" ) .constraint( new NotNullDef() ) .valid() .property( "lastName" ) .constraint( new NotNullDef() ) .constraint( new SizeDef().min( 2 ).max( 14 ) ); The SPI would provide a way for declaring constraints (see above) and functionality used by the BV runtime to navigate over validated types and retrieve the required type meta data for validation. Coming back to JavaFX, there the Employee type could look like this: public class Employee { @NotNull @Valid private final ObjectProperty<Map> address = new SimpleObjectProperty<Map>(this, "address"); @NotNull @Size(min=2, max=14) private final StringProperty lastName = new SimpleStringProperty(this, "lastName"); ... } As of today, the annotations would be of no effect, as there are not validators such as SizeValidator<Size, StringProperty>. But using the SPI, one could hook in an adapter which creates a representation of the Employee type in the abstract model (with e.g. the "lastName" property being of type String), which would allow the BV runtime to operate on it. That said, I'm aware of that this would probably be a large addition, and I'm not sure whether it would be doable at all. For the JavaFX case, also this solution would be imaginable: public class Employee { private final StringProperty lastName = new SimpleStringProperty(this, "lastName"); @NotNull @Size(min=2, max=14) public String getLastName() { return lastName.get(); } public void setLastName(String lastName) { this.lastName.set( lastName ); } public StringProperty nameProperty() { return name; } ... } That's much wordier than annotating the actual properties, though. --Gunnar [1] http://commons.apache.org/beanutils/api/org/apache/commons/beanutils/pack... [2] http://www.devx.com/Java/Article/29093/1763/page/2

Bean Validation already has a mechanism for overriding/adding constraint definitions, namely the XML deployment descriptor. All JavaFX would have to do is to implement the ConstraintValidators for the different constraints and bootstrap Bean Validation accordingly. Of course this could be made easier if there would be also a programmatic way to add constraint validators. Or we try to go the service locator approach and to automate the discovery. I agree. Bean Validation is really centered around Java Beans and classes in general. There is not only the problem of "discovering" the properties to validate, but also how to integrate constraint inheritance, group sequences, etc. Maybe if one thinks about all this very very carefully there is a way to put it all together, but as Gunnar is already suggesting this would imo be a major undertaking which is not suitable for BV 1.1 --Hardy

On 2 juil. 2012, at 19:04, Matt Benson wrote: I was hoping to tackle some of that via the work to be more OSGi friendly but motivated people lost their motivation en route ;) I blame modularity for this :D Being realistic, it will be a while. If we take history as predictor, we will release Bean Validation 1.1 early 2013 and 1.0 was release (very) late 2009. That's a 2.5 year turnaround.