I’ve finally decided how I can make WebWork’s client side validation really work for you. Rather than relying on JavaScript code that is equivalent to the rules on the server side (such as regex, range matches, etc), let’s just avoid JavaScript all together.
Huh? Let me explain:
Right now WebWork’s client side validation library requires that code be written in two languages: Java and JavaScript. I propose that we stick with writing validators in only Java.
Rather, we use JavaScript and XmlHttpRequest to communicate with the server side and check for validation on any onChange event. This would allow for people to any validator they want, avoid worrying about JavaScript, and still give the effect of client side validation.
A sample scenario would be this:
- User enters a negative dollar amount to withdraw from a bank account.
- User presses tab, switching the focus to the next form element
- The onChange event is fired off, sending a request to the server asking if the particular field for that form is valid
- The response indicates it is invalid (along with the error message)
- The onChange event parses that response and uses DHTML to insert the error message in to the form, just like server side validation looks like.
- The user is unable to submit the form because there is a token called canSubmit that is now set to true.
This of course would only work for browsers that support XmlHttpRequest, but that’s OK. For the browsers that don’t, we’d just disable client side validation and let server side validation take place.
This would also be a great start for the future of WebWork: providing a richer set of server-side data binding entirely on the client. In essence, this begins to push it a bit more “even driven”. What do you think?
on Nov 9th, 2004 at 2:42 pm
Sounds interesting.
How will this affect bandwidth? If the connection is slow, will there be a pause every time I tab to a new field?
Browser support could be another issue. People might not choose webwork because this one feature doesn’t work on their favorite browser. Do you know what browsers support XMLHttpRequest?
In all, it’s a innovative idea. Did you mean “event driven” at the end?
on Nov 9th, 2004 at 2:50 pm
Sounds very cool, but my guess is you will be fighting with some browser issues. Of course, this will happen whenever you start working with JavaScript. My guess is that since client-side validation is somewhat new to WebWork - you’re not really “breaking” anything by adding this. +1.
on Nov 9th, 2004 at 2:52 pm
Makes no sense. Just go all the way and implement a full component model a la JSF. Better yet, build on top of JSF.
Still, this is a bad hack. Not all browsers support XmlHttpRequest so you’ll end up doing a POST on every onchangeevent. And then it only goes down hill from there.
The better idea is to generate javascript for the 90% common-case. It can’t be that difficult. Then, introduce an interface, ValidationScriptGenerator, that people plug in their own to generate their own custom javascript if they want.
Goddammit, KISS!
on Nov 9th, 2004 at 2:58 pm
Brian,
Bandwidth shouldn’t be too much of a problem, but I can’t say for sure yet. While there would be a delay between the error popping up, it wouldn’t prevent your browser from letting you do other things (that is because XmlHttpRequest is run on a different thread).
Most browsers support XmlHttpRequest now.
Meeper,
If you used WebWork you’d know we already have done your suggestion.
As for a “full component model”, this would likely be the start of moving in that direction. I said this in my post. I don’t know anything about JSF, but with Struts 2.0 already going down that path, there is no point in re-inventing the wheel.
I also said that for browsers that don’t support XmlHttpRequest (which is very few), there would be no client side validation.
on Nov 9th, 2004 at 3:10 pm
Matt,
Correct — client side validation isn’t really a fully supported feature right now (the roadmap has it being introduced in 2.2). So I think it’s a good time to make this change.
Contrary to what Meeper says, I also think that this is a great way to slowly move the framework in a new direction without requiring a complete rewrite (a la Shale).
on Nov 10th, 2004 at 3:17 am
Sounds pretty interesting, I’ve played with the XmlHttp stuff before, and you can get some pretty cool things working asynchronously. IBM had a pretty good wrapper library for this kind of stuff from what I remember, I’ll see if I can find the post. This also sounds like it would be a pain in the ass to test!
on Nov 10th, 2004 at 8:17 am
Excellent idea. I’m all for it! +1
on Nov 12th, 2004 at 2:43 pm
Part of the REASON for client-side validation is to save the bandwidth and time for a server hit only to find out the data’s not good in the first place.
And now you want a server ping for each [validated] field?
on Nov 12th, 2004 at 3:10 pm
Michael,
I disagree that the reason is to purely to save bandwidth. The reason is to give the user a more useful user interface. If it can be done in the background, while they are still filling out the form, then that is an imrpovement upon filling out the entire form, clicking submit, and THEN finding out the error.
Basically, it’s not about the bandwidth or where the logic happens, it’s about the instant feedback. Now if this turns out to not provide very instant feedback, then it’s not a very good route and we’ll look at something else.
on Dec 20th, 2005 at 5:32 am
I completely agree with Mathias Bogaert. The client side validation is meant exactly for the reason the server side not be “bothered” too much. As for AJAX stuff, I take it the same way as optimization. I would always do it at the end, when everything else works and I have some spare time to enhance the UI.