JavaFX Form Validation

[Tom Eugelink]

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

Since I'm using JGoodies binding all over my Swing apps, I'm not going to be sad about that. :-) Although my opinion sometimes slightly deviates from Karsten's (author of JGoodies), I usually skip his presentation model and work directly on entities, it most definitely is a well thought through approach. Ya can't go very wrong.


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

Good PDF! Not enough time right now to read it with enough dedication.


>
> 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).

Yeah, I know. That's all not so very good, especially when migrating an existing BM to use JFX. There really should be a decent hook into this binding and setter thing. But let's not mix stuff up.


> 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.

Well, setters in the end still can throw exceptions, and these should / could be handled. Why not as as validation errors?


>
>>
>> 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?

Up until now I had mentioned validation directly on the entity and as part of the process (wizard). Assume these two are running remotely, and all of a sudden the connection drops. Then the form itself would require a "ConnectionAliveValidator" to nicely handle that situation.

Yes, this can be handled out side of the validation, since formally it may not be validation. But IF you have a validation functionality available, with all the nice error showing and CSS and happy users, make life easy by reusing it to the max. You get nice representation and maybe logging and stuff. Come to think of it; manually adding validation messages as part of the business process is also such a point. But I've seen that in the PDF I think.


>>
>> 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.

True, but it may be convenient to help them a bit. Sure, it's not that hard to do it yourself; set some variable that indicates a validation context and have the validates check them. But again, Swing Framework, let's create a Form class that has a little bit of administration to assist here.

http://www.jroller.com/eyallupu/entry/jsr_303_beans_validation_using




>>
> 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?

See above. My gut tells me that having the concept of a form (like in HTML) can be very beneficial. It is the natural way to look at a screen; groups of controls. Again, is it required? No, and one could do it yourself, but the concept that a number of button all trigger a submit on the same a form and the form holds the validations over the current set of controls just makes sense and a message renderer can be bound to the form to show them. Swing Framework also added it I believe.

I probably need some thinking time to come up with an irrefutable argument. But with the validation you're stepping a level up from simple controls. Now relations between controls become important.


>
> 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?

No and yes. Hm, I'm not able to put the finger on it. Ask you self the question: if a new JFX would need to create form level validations and checks, where should he put them and how are they visualized? Should we let him invent the wheel or help? If you would place controls in a form (which is something different from layout), then there is a place to collect the messages.

Tom