I’ve been doing development on an internal web application for about 6 years. As the app has grown and we’ve added more forms and a wider variety of controls some of the inconsistencies in the standards have caused issues. For instance something that matches the article: Text inputs have a maxlength while text areas do not. Until recently each page with a text area had a custom script to handle validation of the length. The initial scripts validated length after pressing submit and later scripts tied to the keypress event for a more user friendly cutoff notice. However that’s all wasteful coding and would all be solved by just having a maxlength attribute on the textarea element.
Add the ability to created your own custom attributes and a DTD to tell other agents about that attribute, mix in a little script, and you have a nice easily reusable component. No longer do the designers have to script a special validation for some textarea by ID or CLASS. Simply loop through the textareas on the page, attach the generic keypress handler and use the maxlength to decide the cutoff point for entry.
This is all part of how the standards are supposed to work. Custom elements/attributes are the goal of XML and XHTML. It allows for the developer to create a page that might be used one way internally and yet still be readable/usable by someone on the outside.
We have a redundancy approach to validation. Part of the reason why we do this is to provide the client with friendly interfaces and quicker response times when a validation error occurs. The other reason we do this is because we work within a web service model. Our server side code services more than just our one web client and so we cannot count on those other agents having built in client side validation. We must do validation on both sides.
One additional factor that people may run into is an inconsistency in the way that “valid” data should display on the client vs. the way that it needs to be sent to a back end. (i.e. on the client it validates and displays as (405) 555-5881, the backend legacy system only allows 4055555881). Or as with dates, users might expect to see and enter 2/5/2005 or 2005/05/02 whereas the back end only allows 2005-02-05 12:00:00Z.
It’s not always in the best interest of the user to do a round trip for relatively simple validations. The majority of validations can be done on the client side quite easily. Using this article as ONE example can make it even easier.
Assume that you have all of your validation routines separated out. You create a generic function that loops through the elements on a form when the submit button is pressed. The function checks each elements class for cues on how to validate the field and runs the validation displaying error messages at the end of the validation. The cues would be simple i.e. class=“required date”, class=“optional string”, or class=“required currency”. The notation allows for the script to easily identify between fields that must have data over those where an entry can be validated but can also be empty. It also allows for visual cues to be set via CSS so that the user can easily identify what’s required or not or allow the designer to align fields based on data type.
You can use the concept with Cocoon, STRUTS, XML/XSLT creating XHTML or PHP or JSP or whatever. It’s not only a this way or that solution.
It’s all very simple loops and switch/case statements, very simple class identifiers, relatively no learning curve when used within a team setting. Plus you can create very robust functionality that’s extremely easy to maintain and extend.
E_X_tensibility is the key in all this. We want to keep the content accessible, beautiful, functional, AND be able to add on “perks” like validation, custom controls, or other nice-to-haves, AND be ready for whatever the future holds.
This is one of the things that many frameworks are available for and attempt to eliminate. Unfortunately it’s usually either at the cost of functionality or at the cost of a high learning curve to use the framework.