JavaFX Form Validation

Anthony Vanelverdinghe anthony.vanelverdinghe at
Mon Jun 11 11:24:28 PDT 2012

Hi Jonathan

I wholeheartedly agree with Florian on this. Please have a look at the 
roadmap as well:

It says: "Bean Validation standardizes constraint definition, 
declaration and validation for the /Java platform/." and the expert 
group clearly expresses the intent to accommodate the integration with 
other JSRs: "[...] the Bean Validation expert group will adjust or add 
new features to the core of the Bean Validation specification as deemed 
necessary to achieve a successful integration."

In my opinion it would be a natural choice for JavaFX to make use of the 
framework that is used throughout the Java EE stack already.
The least that JavaFX should do, is to be able to make use of existing 
Bean Validation metadata.

Kind regards


Op 11/06/2012 11:15, Florian Brunner schreef:
> Hi Jonathan,
> From:
> ---------------------------------------
> JBoss' Emmanuel Bernard has submitted Bean Validation 1.1 as JSR 349. This version should be part of Java EE 7 and an important goal for this release is further integration with other platform JSRs.
> In addition to JSF and JPA, integrations with JAX-RS, JAXB, CDI and EJB are also considered. Other important evolutions include a potential API to validate parameters and return values of method calls as well as another API to declare constraints (as opposed to annotations today). The JSR page and this earlier blog post have more details.
> Note that the current Bean Validation API can also very much be used with JavaSE. Ballot results for this JSR are due on July 25th, 2011.
> ---------------------------------------
> Bean Validation is currently developed under JSR 349. The goal seems to be among others a better integration with JSF (which is also a GUI technology) and Java SE. Thus I think JavaFX should be considered as well.
> Regards,
> Florian
> Am Montag 11 Juni 2012, 11:01:13 schrieb Jonathan Giles:
>> Florian,
>> My understanding of JSR-303 is that it is well past the stages of being
>> active. According to [1], it starting in July 2006, and produced its
>> final release (along with final API) in November of 2009.
>> Also, from my understanding of JSR-303, it appears to be more focused on
>> the Java EE needs of a container such as Hibernate (one component of
>> which is the reference implementation of JSR-303). I would imagine that
>> this would lead to it being far more complex than is necessary in a
>> JavaFX API.
>> However, I am not ruling it out, but I just worry that it may be
>> ill-fitting for JavaFX. I would be totally happy to be proven wrong, and
>> will look into it more tomorrow to be sure.
>> [1]
>> -- Jonathan
>> On 11/06/2012 8:47 p.m., Florian Brunner wrote:
>>> Hi,
>>> I haven't worked with JSR-303, yet, but I would appreciate if the Java community could come up with a validation framework which can be used consistently on various layers.
>>> If JSR-303 currently doesn't fit the needs of JavaFX, maybe the JavaFX team could get involved in JSR-303 to make sure it fits the needs of JavaFX as well?
>>> Regards,
>>> Florian
>>> Am Montag 11 Juni 2012, 01:52:10 schrieb Jonathan Giles:
>>>> Hi all,
>>>> I'm currently in the very, very early stages of developing a validation
>>>> API for future inclusion into JavaFX. I thought rather than get too far
>>>> into the research and development of a proof of concept, I would see
>>>> what you all think. Any feedback now would be very useful.
>>>> Essentially, there are a few common styles related to form validation.
>>>> Some of the more likely approaches include:
>>>>     * The 'JGoodies Validation framework' [1] approach, where the
>>>>       developer provides a Validator that will then run over the form and
>>>>       gather feedback to return to the user (for example, it would test
>>>>       that the 'name field' is not empty, and that the email address is of
>>>>       the correct style - if either of these rules are invalid, the
>>>>       Validator would return ValidationMessage instances inside a
>>>>       ValidationResult). If validation fails the user is shown the text
>>>>       out of the ValidationMessage feedback, otherwise the form would
>>>>       submit as per usual. This validation may happen at a number of times
>>>>       (during form submission, when focus is lost, as a key is typed,
>>>>       etc). The nice thing about this approach is that the Validator can
>>>>       be a part of the domain model, the presentation model, or a separate
>>>>       thing altogether.
>>>>     * The JSR-303 approach which uses annotations to indicate the rules
>>>>       applicable to each field. These annotations are on the domain model,
>>>>       and therefore assumes that the form is directly tied to a domain
>>>>       object (which may not always be correct). I think the JSR-303 API is
>>>>       too complex for what is needed in JavaFX, but a similar
>>>>       implementation could be developed with a simpler API that follows
>>>>       this approach.
>>>>     * For lack of a better reference point, the FXForm approach [3] which
>>>>       encapsulates the validation inside a Form object that can be placed
>>>>       in the scene. I know this isn't explicitly (in the case of FXForm)
>>>>       about validation, but I think it is another approach to consider.
>>>> So, what does JavaFX need out of a validation framework? It's really
>>>> five things (I think):
>>>>    1. A way for developers to validate a form by providing some means of
>>>>       specifying rules, as well as a way to specify when it runs, how it
>>>>       is visually represented, etc.
>>>>    2. A way for the validation to impact upon the visual state of the form
>>>>       (using consistent CSS pseudoclass states / style classes, as well as
>>>>       by showing custom overlays, error messages beside the component (or
>>>>       grouped together at the top of the form)). There must be API to
>>>>       specify all of this.
>>>>    3. Convenient API to simplify the validation process [3] (e.g.
>>>>       isEmpty(String), isAlphanumeric(String), etc, etc, etc).
>>>>    4. An API that does not require it be integrated with UI controls.
>>>>       Doing so would prevent 3rd party UI controls to be able to be
>>>>       validated without also implementing the API, which may prove
>>>>       burdensome. Instead, the validation API should be separate.
>>>>    5. A means to integrate nicely with the bindings and properties API
>>>>       present in JavaFX today.
>>>> Of the three approaches above, my personal preference is to follow the
>>>> JGoodies approach as I think it is the most powerful and flexible.
>>>> However, nothing is set in stone and I want to learn what others think.
>>>> Note that at present this research does not extend to considering
>>>> whether there should be API related to automatically generating a form
>>>> from a (JavaFX) bean (and making use of the validation API to ensure the
>>>> input is correct). However, I am not against discussing this topic as
>>>> well, as long as it too integrates nicely with the rules above, as well
>>>> as the validation API itself, obviously. This research may full into
>>>> requirement three above.
>>>> [1]
>>>> [2]
>>>> [3]
>>>> Thanks,
>>>> -- Jonathan

More information about the openjfx-dev mailing list