Bob's Blog

I'm going to continue my series about object oriented validations with ColdFusion by looking at the approach that I've taken to performing server side validations. I discussed the architecture for server side validations in a previous article, so now I want to get down to the nitty gritty of how the actual validations are performed, looking at the code involved.

I'm going to do this in the context of discussing how I added generic regex support to the framework. I want to thank Matt Quackenbush, my regex mentor, for helping me with the required syntax, and with an example for the demo application.

Because one of the design goals I had for the framework was the ability to add new validation types without having to touch any of the existing code, adding regex support was a piece of cake. Here's how I wanted this new regex validation type to work:

• A developer can create a validation rule for an object property of type regex.
• The developer can then either:
  • Specify a single regex parameter, which will be used on both the client and the server.
  • Specify both a clientregex and a serverregex parameter, which will be used accordingly. This will allow a developer to take advantage of ColdFusion regex syntax that would not be valid in JavaScript.
• When processing validations, either on the client or the server, the contents of the specified property will be tested against the specified regex, and if no match is found the validation will fail.

[More]

I have made the code for my object oriented validation framework for ColdFusion available on RIAForge.

The download includes a demo application and set-up instructions. One should be able to get the demo up and running on one's machine in fairly short order. The set-up instructions also include some fairly detailed documentation about integrating the framework with an existing model, which I won't repeat here. I may write some posts about it in the future, but for now, if you're interested, just download the code, take it for a spin, and take a peek under the hood. The code base itself is actually fairly straightforward.

You may recall, if you've read my previous posts on the subject, that this project started out as a proof-of-concept for an object oriented approach to validations. I'm pretty happy with the product that resulted from this exercise, but there is definitely room for improvement and enhancement. I'm very keen to hear from anyone that checks it out and attempts to use it, and I'm willing to help anyone who runs into difficulty getting the demo up and running, or has questions about integrating the framework into an existing model.

Feel free to email me directly or use the google group (groups.google.com/group/validatethis) that I set up to facilitate more of a "conversation".

In this installment of my series about object oriented validations with ColdFusion I'm going to finish the discussion of the architecture of the framework. In a previous article I discussed that because the framework is used to generate both client-side and server-side validations, there are three categories of objects:

• Core Objects, which are used for both client-side and server-side validations.
• Server Objects, which are used only when performing server-side validations.
• Client Objects, which are used only when generating client-side validation code.

That article described the Core Objects and the Server Objects, so that just leaves the Client Objects.

[More]

In this installment of my series about object oriented validations with ColdFusion I'm going to discuss the metadata that drives all of the client and server-side validations, as well as how a developer can describe that metadata to the framework.

We'll start by looking at a sample xml file, the one that is used to drive the demo in fact. I want to make it clear, however, that the framework is in no way dependent on this xml schema. One can create an xml document based on any schema, as long as it includes the necessary metadata. As well, one can load metadata into the framework programmatically, eliminating the need for xml altogether.

[More]

I wanted to thank John Whish for his recent comment on Ben Nadel's blog directing interested parties to the OO Design category on my blog for:

some good stuff at a higher level which is fairly easy to follow

I endeavour to write material that is accessible and I'm always very happy to hear that others are finding value in what I write. I like to think that much of what I've written falls into the "easy to follow" category, particularly the How I Use Transfer series, so I might suggest that anyone looking for "easy to follow" could do well to start with that set of posts.

I certainly don't want to discourage anyone from delving into the ValidateThis! series as well, but I fear it may be a bit more difficult to follow and comprehend than the rest of the posts in the OO Design category, and I wouldn't want to scare anyone off.

Thanks again, John, for the kind words and the link.

In this installment of my series about object oriented validations with ColdFusion I'm going to describe the overall architecture of the framework. I have tried to apply the following object oriented principles as I've been designing this, which should help me achieve the goals described in the first article in the series:

• Encapsulate what varies.
• Don't repeat yourself (DRY).
• The Open-Closed Principle: Classes should be open for extension, yet closed for modification.

Following those principles has yielded a design that results in a lot of objects and may seem unnecessarily complex. I believe that the complexity is required to achieve the goals, but some may disagree. One of my reasons for writing about how I've designed this is to solicit feedback from any interested parties which may solidify and/or change that belief.

[More]