EmmanuelB> It might make sense for us to add support of JavaFX types in EmmanuelB> the spec. Implementations could use some lazy "binding" in EmmanuelB> case JavaFX is not there. Are these types stable and few or EmmanuelB> do they change every other morning? GM> Personally, I find the option of adding support for types of specific GM> APIs/frameworks to BV not really appealing. Maybe another API than GM> JavaFX appears tomorrow? GM> Another problem I see with GUI validation is that one typically wants GM> to validate form values before putting them into the model. This works GM> fine for property-level constraints (using Validator#validateValue()), GM> but we have nothing to offer for class-level constraints here. EmmanuelB> That would mean some small duplication but the form itself is EmmanuelB> an object right? We could put the (class level) constraint EmmanuelB> declarations on it. GM> I'm not really sure. AFAICS the form/controller class would have GM> members of types such as Label, TextField etc, while the a validator GM> for a class level constraint of the model would operate on the bean's GM> attribute types. One could think about creating a second validator for GM> the form types. But I'm not really a JavaFX expert :) For what it's worth, this "validate values before putting them into the model" is *exactly* what the BV + JSF integration has always done, since JavaEE 6. Here's some text from the JSF spec about it [1]. Obtain the ValidatorContext from the ValidatorFactory. Decorate the MessageInterpolator returned from ValidatorFactory#getMessageInterpolator with one that leverages the Locale returned from UIViewRoot.getLocale(), and store it in the ValidatorContext using ValidatorContext#messageInterpolator. Obtain the javax.validation.Validator instance from the validatorContext. Obtain a javax.validation.BeanDescriptor from the javax.validation.Validator. If hasConstraints() on the BeanDescriptor returns false, take no action and return. Otherwise proceed. Call javax.validation.Validator#validateValue, passing valueBaseClass, valueProperty, the value argument, and validatorGroupsArray as arguments. If the returned Set<ConstraintViolation> is non-empty, for each element in the Set, create a FacesMessage where the summary and detail are the return from calling ConstraintViolation#getMessage. Capture all such FacesMessage instances into a Collection and pass them to ValidatorException.ValidatorException(java.util.Collection), throwing the new exception. GM> Today BV is focused on actual Java types adhering to the JavaBeans GM> convention (types with getters/setters), but there are use cases where GM> one may have another type model but still would like to use the BV GM> validation approach. GM> My thinking was to provide an SPI which allows to customize the way BV GM> interacts with type models. This SPI would establish an abstract type GM> model used by the BV runtime. This model would know about "types", GM> "properties" and so on, but these wouldn't necessarily have to be GM> actual Java types with bean properties. Gunnar, is it possible for you to craft this usage of BV in terms of a pattern of invoking the validateValue() method rather then inventing another SPI, which, by its very nature of being "yet another SPI" is bound to be seen as baroque at some level? EmmanualB> Yes I am not convinced there us such demand for such EmmanualB> feature. And that would definitively be a big undertaking. EmmanualB> What do others think? I'd like to avoid it if possible. It's hard enough for one to get one's head around what we have already, when coming in from the outside, and looking at JavaEE as a whole. Ed [1] https://maven.java.net/service/local/repositories/releases/archive/javax/... -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 13 Business days til JSF 2.2 Public Review to EG