JavaFX Form Validation

[John Hendrikx]

Hi Tom,

Just a note, I think your simple validation doesn't go far enough 
already.  I want validation after every key typed, so any bound fields 
would need to accept values that are considered illegal (when entering 
an age > 20, it should not balk after I only typed one character, but it 
should display a marker that the value is not yet within the accepted 
range).

On 11/06/2012 09:13, Tom Eugelink wrote:
> 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.