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.
The Validator
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.
DougHughes.net 
Comments on: "Form Validation – The Rules Live Where?" (10)
For what it’s worth, it shouldn’t be a “form” validator, but more so a generic validator that can be extended. I think the core framework should have no visual aspects to it either. Additional libraries could be provided for HTML and AJAX interfaces, etc. Why? Well, you might want to validate data from a flex system, etc.
Also, I’m thinking that the system as a whole should be (or depend on) an abstract factory that can create and use validators for given objects depending on their configuration. It’d be nice to be able to do something like this:
The validatorSystem could use the metadata to get the class name for the object instance and look up the configured validator.
Also, i think that the validators themselves should have flexible systems for loading their configuration. So you could, for example, by default, use XML, but you could configure the framework to load the configuration settings using a different component if need be. Thus, you could create your own database loader for dynamic forms.
Food for thought
LikeLike
You might want to consider taking a look at the java library Commons Validator. It takes a XML config file and parses it to determine the rules to apply to validate a certain bean (aka object). It even has the ability to output JS validation or server side validation when used with some of the major java web frameworks.
http://jakarta.apache.org/commons/validator/
LikeLike
Kurt – Thanks for the pointer, I will definitely take a look. I am not sure I like tying the validator to a specific display format, but maybe we could look at some sort of extra bolt on type components that would take the error collection returned by the validator and convert that to various display formats.
LikeLike
Just run by me again the benefits of an XML config or DB vs config in code?
I’m a long way from being in the anti-XML camp, and I don’t want to open that can of worms, but I’m just trying to think for this particular use case what the benefit is.
FWIW, my typical validation routine is just a call to a string of validation primitives, and then maybe some multifield logic:
validateNotBlank(field);
validateMaxLen(field, 300,”custom message”);
if (some multi field condition)
addError(“some message”);
etc.
In effect the methods available on the validator object comprise a DSL in the same way that an XML schema would.
Jaime Metcher
LikeLike
Just a few weeks ago I tried to solve similar problem using strategy pattern. Basically each validation rule is a CFC. Then there is a factory that knows how to initialize those. Each concrete strategy implements same method, and gets an object that encapsulates a struct with form data. Strategy knows what it needs from that struct and also each strategy can be coded to this common API. Not sure if I explain it well, this ofcourse would be just one piece of the puzzle. Here is an example of a strategy CFC. The init data is in the DB.
super.init(argumentCollection=arguments);
variables.formkey = arguments.formkey;
variables.vallist = arguments.vallist;
return this;
var valtocheck = arguments.formObject.getFormFieldValue(“#variables.formkey#”);
return listFindNoCase(variables.vallist, valtocheck);
This was not used very much yet so I am not sure if approach fully works. In my head it does though… 🙂
LikeLike
oops no code! can I post CF code?
LikeLike
<cfcomponent name=”StrategyInList” extends=”BaseStrategy” output=”false”>
<cffunction name=”init” access=”public” output=”false” returntype=”BaseStrategy”>
<cfargument name=”formkey” required=”true” type=”string” />
<cfargument name=”vallist” required=”true” type=”string” />
<cfscript>
super.init(argumentCollection=arguments);
variables.formkey = arguments.formkey;
variables.vallist = arguments.vallist;
return this;
</cfscript>
</cffunction>
<cffunction name=”check” access=”public” output=”false” returntype=”boolean”>
<cfargument name=”formObject” required=”true” type=”struct” />
<cfscript>
var valtocheck = arguments.formObject.getFormFieldValue(“#variables.formkey#”);
return listFindNoCase(variables.vallist, valtocheck);
</cfscript>
</cffunction>
</cfcomponent>
ok had to try….
LikeLike
Jaime – I don’t know that there are any clean cut rules for using XML vs. a database. For that matter, you could throw in INI files, or text files, or any number of any other options. Since ColdFusion has the ability to easily parse XML now, it has gained favor for configuration files.
For my personal preference, I typically will use XML files for application configuration information. If there is configuration data that is more fluid (i.e. business rules that an administrator can change on the fly) these would typically go to the database as it is easier to make changes there rather than doing file IO. Again, this is personal preference, but it the way I have found it easiest to do things.
LikeLike
We have in the past purchased and used Terraform from eswsoftware.com. That project seems to be dead but it had form generation and validation nicely implemented. You can still download a demo. Take a look at it. Something similar would be very nice.
LikeLike
I’m going to second Rz about looking at Terraform. I use it extensively and the validation is very well done. A new beta version was released a year ago but nothing since then. Here is the url to the sample gallery: http://www.eswsoftware.com/products/terraform/gallery/
LikeLike