JavaFX Form Validation

[John Hendrikx]

I do tend to agree with Tom, JavaFX should provide the means for tight 
integration of *a* Validation system, but it doesn't necessarily have to 
provide one out of the box (although it could of course).

I do think however that any validation framework offered by JavaFX 
should be re-usable outside its scope without the use of 
Platform.runLater() calls everywhere, otherwise you will end up with 
complex applications that need two different frameworks because one of 
them is tied to the UI part of JavaFX and cannot be re-used for input 
coming from different sources.

--John

On 11/06/2012 10:57, Jonathan Giles wrote:
> 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
>>>>
>>
>