DougHughes.net

Form Validation – Why Can't It Do Both?

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?

Form Validation – The Rules Live Where?

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.

Form Validation – How do you do it?

We all know, or at least should know that server-side validation of form data is a must – whether or not you use some sort of client-side validation. I have worked on quite a few projects and it seems like every project handles this a bit differently. In my mind, form validation could very easily be standardized so that we would not have to reinvent the wheel with each application. There are very complete JavaScript libraries out there such as qForms, so why is there nothing in ColdFusion?

Today, we are going to fix this. If you were tasked to build a ColdFusion server-side form validation library, what would it look like? Suppose the following requirements were given and lets see what kind of creativity can be applied.

1. The validation library should be able to be dropped into any application and validate any type of form. In other words, there needs to be a clean “language” for specifying things like required fields, field types (text, numeric, postal code, bank account, etc.), error messages, and the like.
2. The rendering of the error messages needs to be flexible … whether they are displayed in a single list, next to the associated field, in a JavaScript pop-up, or whatever … that should be up to the end developer/designer.
3. The validation library should be extensible. No matter what kind of functionality is implemented, there will always be a weird validation rule that needs to be created for some application.
4. The validation library should be able to support validating an entire form at once vs. validating one field at a time. In other words, the developer should be able to validate the form on submit and redisplay the form with errors, or he/she could use some sort of AJAX call to validate a specific field or fields upon an event.

So, while these requirements are not trivial, this leaves things pretty wide open. If you were tasked with building something like this, how would you do it? I have some ideas, but rather than limit peoples creativity, I want to see what can be come up with first.

What's the Difference?

So, what is the real difference between Object Oriented and Procedural Development?

In my last article, I listed a few of the benefits of object oriented development. It was justifiably pointed out that many of those same benefits could be applied to procedural development as well. So, I would like to take a moment and outline the real difference between Object Oriented development and Procedural development.

As a brief disclaimer, my intent and purpose here is not to say that object oriented development is the best and only way to write applications. Many developers have spent their entire development career writing procedural applications without any issue and there is no problem with that. My intent here is to shed some light on some of the basic concepts of object oriented development now that ColdFusion is trying to enter the land of object oriented development languages.

The Difference

To start, what is procedural development? Procedural development is very functionally based. In other words, with procedural development, the developer develops solutions to problems. Good, clean, organized procedural development, code is broken up into smaller functions and modules that perform a specific function. These functions then act upon data that is organized into separate data structures.

So, where is the problem here? With procedural development, the data is very unpredictable. Multiple functions have access to global data, so they can only assume what the current state of the data is, as the functions have no control over that data. Because of this unpredictability, testing and debugging can be very challenging at best.

On the flip side, instead of focusing on functionality, object oriented development is much more on what the functionality is being done to. Object oriented development starts off with things, or objects. But instead of just being collections of functions, these objects have both data and behaviors.

In this way, objects can secure access to data, thereby protecting it and being aware of its state. Correctly designed objects only allow access to data through specific behaviors or functions. This way, changes to the objects data may be monitored and sanitized.

What is an Object?

So, what is an object really? As mentioned before, an object is made up of attributes and behaviors. A person is an example of an object. A person has attributes hair color, height, and weight. A person also has behaviors walk, eat, and sleep. The biggest key here is that an object is made up of both data and functionality.

Objects have Data

With a properly design object oriented system, there is no such thing as global data. Each and every object maintains its own data set the data that it needs to perform its job and only that data. A person object would know about its hair color, but a car object has no need for this type of data.

By keeping and maintaining its own data set, the object always knows the state of this data. In a properly designed system, the object should be the only thing that can act upon this data. Looking at the case of a person object again, would it make any sense for some other object to have control over that persons weight? What would happen if that other object set the persons weight to a negative value then, we would have invalid data and be no better than procedural development. Here is where object behaviors come into play.

Objects have Behaviors

Behaviors are the functions from procedural development. With object oriented development though, these functions are grouped according to their relationship to the object. A person object would have behaviors such as walking, eating, and sleeping. A car object on the other hand would have no need to know how to eat. Functionality is unique to that object.

In addition to general functionality, behaviors serve to protect the data managed by the object. As mentioned above, one object should not be able to change the data in another object. This is accomplished by the use of specialized behaviors called getters and setters. As their names suggest, getters get data from the object while setters set data in the object. In the example above, if a setter function were used to set the person objects weight, that setter function could have some logic built in to know that a persons weight cannot be below 0, so it would throw an error if a negative value was attempted.

Thats a wrap for today

Hopefully at this point, you have the basic understanding of what an object is and how it differentiates procedural development from object oriented development. What you must realize at this point as a developer is that object oriented development is not just a new syntax or set rules. Object oriented development requires the developer to adjust their thinking into terms of objects and systems rather than simple solutions. This is not a trivial change, but is possible and will benefit both you and your clients when you can design code that is easy to test, debug, and reuse.