JavaFX Form Validation

[Tom Schindl]

Hi,

I don't think it is the task of JavaFX to provide a validation system.

All it needs to provide is an API on the controls to show validation
results.

Tom

Am 11.06.12 09:13, schrieb Tom Eugelink:
> Hi all,
> 
> Ah, a topic that is close to my heart. Personally I'm big on reuse, so
> initially approach 1 seems to come closest. However I'm even a bigger
> fan of clear separation, and having a form validation in a domain model
> is debatable. Here is my brain dump;
> 
> Normally, one would split out the validation activity around a form in
> multiple parts;
> 1. simple validation; usually these kinds of validation are implemented
> directly on the setter, like "age >= 0" and can be displayed immediately
> after the field is exited / committed. Normally one would use a
> IllegalArgumentException in the setter to enforce it, contrarily to
> annotations on the setter, an IAE is enforced always and requires no
> reflection on the UI side. However the current bindings do not allow
> proper handling of this (see my blog post of a year back).
> 
> 2. grouped validation; these are validations between fields, things like
> "before < after". You could do this in the setters, but that usually
> creates entry issues. So this needs to be in some kind of post setter
> validation call on the entity, probably on submit of the form.
> 
> 3. general on submit form level validations, the mandatory fields fall
> into this category. You could try to merge this with grouped validation.
> 
> 3. But not all forms are directly bound to entities, for example a
> wizard collects all kinds of information and usually only in the end are
> entities involved. These forms usually are backed by a backing class,
> which basically has the same validations features as entities, only do
> not reside in the domain model.
> 
> 4. 99% of all the validations would fall in the contexts above, but
> there is always that form specific thing. So a form internal validation
> is required as well.
> 
> 5. Lastly grouping and enabling. You can use forms in different
> contexts, e.g. editing an entity or a template (which is then used to
> easy create new entities). Such a template probably has a lot of
> constraints disabled. So it would be good to be able to partially
> disabled groups of constraints for a form.
> 
> Summary:
> - per field direct validation
> - on submit validations
> - both in directly in the entity or on backing classes (or a combination)
> - form internal validation
> - grouping and enabling
> 
> Personally I would go for an approach where a validator can be
> registered to any control or container. There could be an easy
> reflection based implementation which is parallel to the binding; so if
> you bind the control to an property on an entity, a validation also is
> set that looks at the annotations of that property, maybe even
> automatically. A form can be bound to an form validator. But it is
> always possible to create ones own validator and override the behavior.
> Since we need something of a "form" class anyhow, the context of the
> validation (what is enabled and what not) should be set there. A
> validator can be be assigned one or more group ids, and call for
> validation gets the form as a parameter, implicitely giving it access to
> the validation context, so it can check if it is enabled or not.
> 
> Makes the above any sense?
> 
> Your 5 summary points are perfect. How to visualize, external to the
> controls, join up with binding. Yup.
> 
> Tom
> 
> 
> On 2012-06-11 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/
>> [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
>>
> 


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834