JavaFX Form Validation

[Jonathan Giles]

Tom,

It is perfectly valid to argue against adding more API to JavaFX. Heck - 
the less I have to maintain the happier I am, so I'm (nearly) on your 
side! :-)

I don't have a compelling argument for including validation support in 
JavaFX, however I think the best argument I have is that it is likely to 
be something required by the vast majority of developers. Just having 
support for showing validation results seems to me to be a little too 
low-level given the assumed needs of most developers (in my very humble 
and gut-feeling opinion).

I also think that it is likely that by being part of the core JavaFX API 
it would allow for validation support to be baked in at a lower level 
(in particular better UI styling in the case of validation failures).

-- Jonathan


On 11/06/2012 7:21 p.m., Tom Schindl wrote:
> 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
>>>
>