There's a scene in The Hitchhiker's Guide to the Galaxy that goes:He reached out and pressed an invitingly large red button on a nearby panel. The panel lit up with the words Please do not press this button again.
Clearly this is a joke: it's funny because it's obviously bad user interface design. Yet this is precisely where we are today with Java EE 6.
Don't get me wrong: I think Java EE 6 is an awesome spec, and I think Bean Validation and JSF2 work really well together, but just like Seam's s:validateAll, the best you can do is validate the input after the user interaction:
- give them a text box, then afterwards tell them their input was too long
- give them a text box, then afterwards tell them number must be less than 100
- give them a date picker, then afterwards tell them date of birth must be less than today
- give them a text box limited to a certain number of characters
- give them a number spinner (or slider) capped at 100
- give them a date picker capped to before today
There are a variety of ways to achieve this, and obviously I'm biased. But whichever approach we use, I think it's the next logical step - and the final frontier in establishing validation constraints that apply all the way from the back end to the front end.
2 comments:
Absolutely. We should be using the metadata that Bean Validation provides (and perhaps other useful metadata) to create the right user interface that provides maximum usability.
Now you could argue that this is just a detail of the application design (i.e., the grunt work), but I think that assemblers such a MetaWidget prove that this can be accomplished with relatively little pain. So keep the flame burning ;)
I fully agree: as a user, I am always upset with bad GUIs that tell me I gave bad input after the act. It is unforgivable in desktop applications, and it was good only in Web 1.0 applications (with CGI back-end...). The worse are these forms erasing all input instead of letting you to fix a typo...
So, as a coder, I always try and provide up-front validation with useful and gentle warnings if input is wrong. It is much more work on my side, but so much better for the user!
Now, at least with Web applications, it doesn't prevent a second validation at server side! Perhaps that's where that spec is useful...
Why a second validation? Because on Web browsers, one can deactivate JavaScript. And if you make it mandatory, one can use stuff like Greasemonkey or Firebug to alter the validation logic. And if that's not enough, they can use a proxy to alter data sent to the server, or even forge requests with cURL or other tools...
Either for testing, to by-pass frustrating validation ("why my e-mail address must be all lower case!?") or for malicious purposes...
Post a Comment