In one of my last postings ( Form Validation – How do you do it? ), I brought up the concept of a generic server side form validation library for ColdFusion and I was quite pleased with the response. Given this, I would like to keep this discussion going and look a bit deeper into some of the concepts that were raised in the comments for that posting.
My goal with this is to come up with a set of requirements and concepts, such that this library could actually be built and then made available to the developer community. The biggest problem will be making it flexible enough to fit most cases with a minimal amount of customization required. This is where you come in – you know your applications and where a solution like this might fit. Let me know of any edge cases that may be being overlooked.
XML vs. database vs. what else?
From the discussion last week came the topic of where to store the various validation rules. Somewhere, somehow, we need to be able to maintain a set of validation rules and be able to assign those validation rules to a given form and the form fields within that form. These validation rules could be simple required or not type of requirements, or they could be very complex requirements – a non-negative integer value between 300 and 500 that is divisible by 20.
My personal preference is to keep the user interface display code as clean as possible, so while Macromedia’s / Adobe’s solution of putting hidden form fields ( LiveDocs ) is interesting, I don’t really like cluttering the form like that, or depending upon code that might be susceptible to a user hack attempt. So, this leaves us with some sort of other configuration concept to specify specific validation rules for a given form and form field.
In the past, my solution to this has always been some sort of xml definition file which has worked reasonable well. The biggest problem is that the file can get quite large based upon the number of forms and form fields in an application. However, with the right style, the xml definition can still be quite useful. The other requirement mentioned as to setup validation rules for a dynamically built form – think of a survey or similar type application where an administrator could add and remove questions from the form. In this case, while an xml file could still work, a database solution might be better.
So what is the answer for where to store the validation rules? My answer is where ever you want.
Since I tend to approach most things from an object oriented standpoint, my thought is to have a validator object. This validator object would have public functions to validate a given field or an entire form to suit the previous list of requirements. The key here is that this validator object would have in its possession a collection of form validation rules which it could then apply. By maintaining a sense of abstraction, the validator object does not need to know where these rules are coming from – be it an xml file, a database table, or who knows where.
This is where a helper data access object comes into play. If you want to put the validation rules in an xml file, there would be a validator data access object that would know how to read and parse the xml file. The core validator object then would just have to call the load method on this data access object to get the set of validation rules it needs. Then, if the next project requires the validation rules be stored in the database, all that needs replacing is the data access object and the validator object is none the wiser.
With that, let’s open up the comments for day and see where this leads.