Over the last few days, the concept of a validation engine for ColdFusion has been tossed around in several blog posting ( Form Validation – How do you do it?, Form Validation – The Rules Live Where? ). One of the primary goals being discussed for that validation engine is flexibility. In other words, the validation engine must be able to be dropped into any scenario with as little customization as possible.
Reusable Validation Plug-ins
When you think of validation, one of the first things that comes to mind, is all of the validation rules that the data must be checked against. How do you make a validation engine that has rules for every possible case? The short answer is you don’t.
Instead of making this super smart validation engine that knows how to do anything, one possibility is to use plug-in validator modules that give the validation engine a way to validate data. For example, if you wanted to be able to validate dates, you might have a DateValidator component that was injected into the validation engine. That component would have a known interface which the validation engine could then used to validate data that should be of type date.
By following this style of model, it would be very easy for a developer to inject a series of specialized validator components into the validation engine to fit the requirements of their specific application.
Pluggable Validation Engine
In the comments for one of my earlier postings, Peter Bell mentioned that his preference is to insert data into business objects (beans) and validate it there rather than validate arbitrary strings or structures. While this is not my personal preference, I was talking with Doug about this and the question arose … why not make the validation engine flexible enough to do both?
What if, in the same manner as the plug-in validator modules, the validation engine itself was pluggable in the way it obtains the data to validate? What if there was a structure reader plug-in (for lack of a better term) that knew how to get all of the key / value pairs from a structure and treat those as data values to validate? Along the same lines, there could be a bean reader plug-in that knew how to get the meta data for a business object and use all of the getter functions to get the data from the bean to validate.
This concept is still up in the air, but I wanted to throw it out there and see if anybody else had any thoughts or ideas?
DougHughes.net 
Comments on: "Form Validation – Why Can't It Do Both?" (11)
You could put some additional metadata inside each function to tell the validation engine how to validate.
For example
Then when you getMetaData, simply extract the key/value pair from the metadata for each ‘get’xxxx function and throw it into your validator.
This way, you could easily support custom rules as well as have the validation metadata tied to the specific function.
Dw
LikeLike
DW – That thought had come to mind, but the question then becomes how tightly are you coupling your business objects to the validation engine and vice versa?
While it would be nice to have all of the validation rules and data in one place does that weigh heavier than the ability for the validation engine to be able to work on any business object with some separate configuration file?
LikeLike
When I first saw this discussion, two thoughts came to mind.
1. Why build one engine to rule them all? That’s impossible. Just build a framework that accepts validation plugins. And ship it with a standard library of plugins to handle the most common use cases. Kinda like Fusebox 5 and its tags.
2. Quit talking about it and just build the damn thing. I would start small. Make it simple and stupid and so rigid that it only works on one form. Then make it work on another form and refactor. Add another form, refactor again, etc. After a while it should start to look like the pluggable validation engine you described (or something better that we hasn’t occurred to us).
LikeLike
I agree with Patrick. It doesn’t seem like it would be that hard to create it cross-context. The vision your idea triggers in my mind is a FormValidator object that takes a structure of fields to validate and an array of associations between field names and validator plugins (either separate CFCs or simple UDFs), of which the standards come pre-built: required, numeric, date, SSN, etc.
Creating a bean-wrapper class that just calls getters and sticks the results in a struct seems fairly trivial. Then just pass the struct to the FormValidator,
I see two areas of “stickiness”:
1) One of the things that would be important (to me, anyway) is to make the validation rules be universally useable to both the client-side and server-side validation. I completely agree that server-side validation is a must, but in this day and age, so is client-side. MOST people have JS turned on, and if you don’t validate client-side and make them take the extra round-trip to the server, you piss off the majority for the sake of the minority. Yet you have to cover for non-JS browsers, so server-side is also required. However, it would be nice to write your validation rules once and have both validators use the same set of rules. But how do you implement that in such a way that you don’t have to write validator plugins for both languages (CF and JS)?
2) How/would you create dependencies, i.e. FieldA and FieldB are mutually exclusive or conditionally required.
LikeLike
Jeremy – Could you offer some more details regarding having both client-side and server-side validation running on the same set of validators? Would this just be a matter of using Javascript AJAX calls to call the ColdFusion validator engine? Or are you thinking that the validator engine would generate Javascript code or something?
As for dependency rules, that would be part of the part of the plug-in validators. I know it is possible, I just don’t have it real clear in my mind yet as to the exact implementation.
LikeLike
This may be a bit off-topic, but since Doug produced Reactor, I was wondering if you every thought of leveraging the dictionary files to do form generation and validation. Obviously it’s a restrictive solution, but if you’re going to be specifying some rules somewhere you might as well only do it once…
LikeLike
@Jeff
I don’t have any details. I’m only in theoretical discussion at this point. Although, notice that I said univerally available rules, not necessarily validators. I don’t see any way to actually use the same code as validator plugins on both sides (unless you wanted to write them in VBScript or something – *shudder*), but the rules themselves could be expressed as XML, which would be consumable by both client-side and server-side validators, if the rules were abstract enough to be descriptive rather than actual code.
If we’re trying to create a single validator plugin that would work for both server- and client-side, there are two quasi-solutions I can think of to simulate writing once for both. One is as you suggested, using Javascript to call the CF validators via AJAX, which bears the advantage of truly only having code in one place, but is not technically client-side navigation. Though the difference to the user may be negligible, the purist in me curls his lip a little bit.
The other solution would be to build a converter, similar to what Adobe did with their Coldfusion extensions to Flex Builder. With those installed, you can click on a CFC and convert it to an AS3 class, and vice versa. I’m sure something similar could be written for CF-JS conversion. But then again, developing that that might be too much buck for not enough bang.
LikeLike
@Jeremy
I really think you should give AJAX more consideration. The other methods are too complex, rigid, and error prone — for obvious reasons.
But nevermind all of that. AJAX has a killer app that makes it a clear winner: You can validate against information on the server side in real time.
For example, if I’m signing up for an account, a validator running on the server could tell me the username I just entered is already taken.
LikeLike
@Patrick
Oh, don’t get me wrong. AJAX is definitely in my toolbox. I’m just not sure it’s a cure-all for all life’s maladies, but it’s a slick technology for certain situations. My point was only – and your example demonstrated this perfectly – the subject at hand is Form validation. I would submit that checking whether a username exists or not (while a very desireable thing well suited to AJAX) does not really qualify as Form validation, which is the topic at hand. If what we’re really talking about is simple type- and required-checking, it seems like a trip to the server should not be required.
LikeLike
Has anything resulted from this dicussion? I’m really interested if CF is the way to go.
I went to a CFMX7 advance training, and the instructor suggested that a javascipt solution is more feasible.
LikeLike
How to reflect same field values one form to another viceversa in coldfusion?
LikeLike