Just read a pretty decent article on a generic form validation technique here. I bet it wouldn’t take much to extend the technique to also validate by id for more complex validation (similar to/leveraging commons-validator). It would validate the class first (to make sure it is at least of the right type) then move on to more complicated validation against the id (to handle ranges for example). If you’re in a web framework, you could make it dynamic and load the id-based rules from a generated page, otherwise adding ‘validateX’ methods where ‘X’ is the id of the element you want to do further validation on could suffice.
April 29, 2005 at 11:52 am
I read an article awhile back about using AJAX to do your client side validation, thus merging the client and server side validation to one. The technique described in this post seems like a nice scripting way to do validation, but you basically have the validation in 2 places. Where as if you used AJAX you could consolidate your validation to a single server side location and not have to submit the page and wait for a response from the server. In other words you could do it on the fly as the user entered each field notifying them as they go. Just a thought.
April 29, 2005 at 12:16 pm
My problem with that is, while it isn’t loading as much, you still lose some of the benefit of client-side validation in that you still have to hit the server. While it isn’t a page reload and not a lot (presumably) of data coming back, you still get a hit on the server. You will still have to do the server side on the ‘real’ submittal of the form.
I’m confident that a solution can exist that would take advantage of a single validation def file that can be declarative and used (generated) for both client and server side validation.