JavaFX Form Validation

[Jonathan Giles]

Thanks Tom for your response. I'm going to approach this email as an 
advocate for my preferred approach - the JGoodies validation approach. 
This does not mean that my preferred approach is right, so feel free to 
disagree! My comments are inline.

On 11/06/2012 7:13 p.m., 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;
It is totally fair to say that validation in the domain model is 
debatable. However, approach 1 does not force this approach. Refer to 
the following link for a PDF containing a number of approaches to 
validation that the JGoodies approach offers:

http://www.jgoodies.com/download/presentations/validation.pdf

>
> 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).
In JavaFX setters are final methods, and putting any logic into them 
(when a property exists) is fundamentally flawed as the setter logic is 
not guaranteed to be executed (e.g. setFoo(bar) is the same as 
fooProperty().set(bar), and this completely bypasses the setter logic). 
The obvious response to this is to put the validation logic in the 
property set method. Unfortunately, in this case, it is too late - the 
value has already been set (and events fired).

Therefore, I would imagine that without support for vetoing property 
changes, this is a non-starter. I would think that a better approach is 
to use the JGoodies approach of providing a Validator, and simply 
configuring when the validation should occur to suit the needs of the 
application.
>
> 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.
Agreed. So, in my current position of favouring the JGoodies approach, 
this requirement is supported as-is.
>
> 3. general on submit form level validations, the mandatory fields fall 
> into this category. You could try to merge this with grouped validation.
Again, covered by JGoodies 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.
Same again: covered by JGoodies Validation.
>
> 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.
Can you expand here?
>
> 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.
In the JGoodies sense, this is completely in the control of the 
developer - they are the ones creating the Validator, and they can 
control what tests are run as part of it.
>
> 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.
I'm not sure we've quite crossed the bridge regarding needing 'something 
of a form class anyhow'. To me, so far anyway, there is no clear 
requirement for a Form class. Can you expand on what this would provide?

In fact, I'm not sure we even need to register a Validator on a control 
or container. Instead, a Validator could be initiated by a developer as 
part of their usual form submission code (e.g. an action event on a 
Button). Again, is there a compelling reason that I am missing?

Thanks,
Jonathan