JavaFX Form Validation

[Jonathan Giles]

Christian,

Thanks. I'm unfamiliar with the Flex approach, but will spend some time 
tomorrow getting to know it so that I'm better informed.

I agree with your concerns regarding support for validation using 
annotations. That is a big sticking point against this approach.

-- Jonathan


On 11/06/2012 7:32 p.m., Christian Schudt wrote:
> Hi all,
>
> I don't know the JGoodies framework, but I do know the Adobe Flex 3.5 validation framework, which seems to be very similar, from what you described (JGoodies).
>
> Basically you have an (abstract) Validator class, with concrete default implementations like EMailValidator. A validator has a source property (which is the Control to validate) and a String property which points to the property name of that control (this could be done nicer in Java with ObservableValue instead of String, default would be textProperty()).
> Furthermore you can specifiy the control's event which should trigger the validator and a listener (the default listener is again the Control).
> This could be a little bit more inconvenient, since the focus lost event is just a property change.
>
> The control then listens to a ValidationResultEvent and displays a validation message from the event object.
> That also means that (each?) Control has to implement an ValidationListener interface.
>
> That's it basically. There is a little bit other stuff like ValidationSummaries and so on.
> It's very flexible. If you want to make a custom validator, just derive from abstract Validator and provide your own logic.
> If you want to add other ValidationResult listeners, just tell it the Validator.
>
> ====
>
> JSR 303: Alluring, but.... I've done a very simple validation with this approach since I thought it is the cleanest way. But the need of a domain model, which matches exactly the form, can be cumbersome, especially if you have to validate if field 1 matches field 2 (e.g. in the case, if you want to validate two passwords to be equal).
> Furthermore you don't have direct access to the control, but only to the domain model you are validating, which can be troublesome.
> Furthermore I needed to write logic to enhance a domain object (pojo) with JavaFX properties, in order to use binding!
>
> But maybe all these little disadvantages can be solved in a nice flexible way.
>
> I also feel, that the first approach is the most flexible one, but the JSR 303 is also nice, if you can manage to design a good flexible api.
>
> Kind regards
> Christian
>
>
> -------- Original-Nachricht --------
>> Datum: Mon, 11 Jun 2012 11:52:10 +1200
>> Von: Jonathan Giles<jonathan.giles at oracle.com>
>> An: "openjfx-dev at openjdk.java.net"<openjfx-dev at openjdk.java.net>
>> Betreff: JavaFX Form Validation
>> 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
>>