JavaFX Form Validation

Jonathan Giles jonathan.giles at oracle.com
Sun Jun 10 16:52:10 PDT 2012


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] http://www.jgoodies.com/freeware/libraries/validation/
[2] https://github.com/dooApp/FXForm2
[3] 
http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html

Thanks,
-- Jonathan



More information about the openjfx-dev mailing list