JavaFX Form Validation

Mon Jun 11 02:22:36 PDT 2012

Hi there,

I agree to Tom Schindl. We for example have a validation system in place (and i guess many others have too) and i've simply added methods to validate/invalidate controls. This is a very general approach that makes it possible to use different validation systems. But i also agree that it would be nice to have a validation system that comes with JavaFX in case you don't have one but it should not be bound to the controls.

Just my 2 cents...

Cheers,

Gerrit

Am 11.06.2012 um 09:21 schrieb 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