JavaFX Form Validation

[Slavko Scekic]

I agree with everything Randahl said, especially the internationalization
part.

Also, if we're considering bean validation, we must take into account that
sometimes forms can be backed by multiple beans (person and contact
informations, for  example). If I remember correctly, Daniel (Zonski)
created some sort of validation framework based on JSR303 (namely Hibernate
Validator), which is limited by having to choose only one bean per
controller to validate. But, nevertheless, he started a good argument on
the subject on the JFX OTN Discussion
Forum<https://forums.oracle.com/forums/thread.jspa?messageID=10291836>.
It would be good to have his input on this too.


On Mon, Jun 11, 2012 at 1:08 PM, Randahl Fink Isaksen <randahl at rockit.dk>wrote:

> Hi Jonathan
>
> Thanks for starting an open debate on this. I have a number of additional
> points for the validation API wish-list:
>
> 1. Decoupling from internationalization mechanism: Other validation API's
> (like the one found in JSF 1.x) require developers to use property files
> for the validation messages gathered. This is a bad choice, since some
> organizations store their internationalized messages in central systems, in
> which message spelling errors can be fixed without rebuilding the app.
> Solution: Ensure that the application - not JavaFX - decides where messages
> come from - it is fine to support the use of property files, but such use
> should never be a requirement. A sound design will provide an pluggable
> mechanism for retrieving message resources, and deliver a default mechanism
> which supports property files, which can be replaced if needed.
>
> 2. Support for validation dependencies (ordering): If a UI has 2 input
> fields A and B, it is sometimes the case, that it makes no sense to run B's
> validator before A has been edited by the user to a valid state. One such
> example is, if B is only a required field for some values of A. It is a
> really annoying/confusing user experience to enter just a single character
> into the A field only to see all other fields of the UI turn invalid (in
> this case B). Instead, allow dependencies so developers can express that
> the validation of B does not start before the validation of A is valid.
> This way, the UI will tell the user that A is invalid and needs to be
> edited, and only after A has been edited to a valid state, will the UI tell
> the user that now B has to be edited. Apart from the improved user
> experience, this is also a much less resource intensive approach to
> validation (recall that in some cases validation may require network
> communication, etc.).
>
> 3. Support group validation: One of the areas where the JSF 1.x validation
> framework failed miserably, was the lack of multiple field validation. Say
> a user enters a date interval using two fields called Start and End, and
> the requirement is that the End date has to be later than the Start date.
> The problem with JSF 1.x validation was, each validator was always tied to
> a particular field, not multiple fields or the form as a whole, so there
> was no way that the Start field's validator could check if the value was
> earlier than the End value. As an application developer, you do not want to
> define both that Start comes before End and that End comes after Start, you
> want to define just one thing: Start < End. So ideally, you should be able
> to write validator, which look at a number of fields, where looking at a
> single field (as some validators do) is just a simple case of "a number of
> fields".
>
> 4. Support full plug-and-play reusability: Reusing a component in
> different applications requires not only the ability to reuse the visual
> component's presentation logic, but also the ability to reuse the
> validation logic and messages which applies to that particular component.
> Say I am developing and selling an EmailAddressField component for JavaFX.
> For that component to be valuable to other organisations, it has to include
> logic for validating e-mail adresses, and it has to include proper default
> messages such as "An e-mail address must contain exactly one @". JavaFX
> should allow me to provide this message in many different languages allong
> with the validation logic and share this alongside the component.
>
> Finally, from what I have seen of the JGoodies approach, it looks very
> procedural, and very programming intensive. I found this example online:
>
> |public ValidationResult validate() {
>    ValidationResult result = new ValidationResult();
>    if (ValidationUtils.isEmpty(**mUser.getUserName())) {
>      result.addError("User name is required");
>    }
>    if (ValidationUtils.isEmpty(**mUser.getPassword())) {
>      result.addError("Password is required");
>    }
>    return result;
>  }|
>
>
> Even though the validation logic to check for emptiness is reusable, the
> developer still has to write a lot of if-then logic. I would much rather
> want JavaFX to have an object oriented approach, allowing me to write
> something like
>
> TextField userNameTextField = new TextField(new UserNameValidator());
>
> where the UserNameValidator class does all of the JGoodies stuff above for
> me and can easily be reused among different parts of my application. With
> this approach it is obvious that people will start sharing
> EmailAddressValidator, ConfigurablePasswordValidator,
> LicensePlateValidator, etc.
>
> Yours
>
> Randahl
>
>
>
> On 11/06/12 01.52, Jonathan Giles wrote:
>
>> 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/<http://www.jgoodies.com/freeware/libraries/validation/>
>> [2] https://github.com/dooApp/**FXForm2<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<http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar%21/com/jgoodies/validation/util/ValidationUtils.html>
>>
>> Thanks,
>> -- Jonathan
>>
>>