Photo from Chile

Performing Server Side Validations Using Objects

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.


ValidateThis! - Object Oriented Validation Code Available at RIAForge

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 ( that I set up to facilitate more of a "conversation".

ValidateThis! - Client Side Validation Architecture

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.


ValidateThis! - Let's Talk Metadata

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.

view plain print about
2    <properties>
3        <property name="UserName" desc="Email Address">
4            <rules>
5                <rule type="required" contexts="Register,Update" />
6                <rule type="email" contexts="Register,Update"
7                    failureMessage="Hey, buddy, you call that an Email Address?" />

8            </rules>
9        </property>
10        <property name="Nickname">
11            <rules>
12                <rule type="custom" contexts="Register,Update">
13                    <params>
14                        <param methodname="CheckDupNickname" />
15                    </params>
16                </rule>
17            </rules>
18        </property>
19        <property name="UserPass" desc="Password">
20            <rules>
21                <rule type="required" contexts="Register,Update" />
22                <rule type="rangelength" contexts="Register,Update">
23                    <params>
24                        <param minlength="5" />
25                        <param maxlength="10" />
26                    </params>
27                </rule>
28                <rule type="equalTo" contexts="Register,Update">
29                    <params>
30                        <param ComparePropertyName="VerifyPassword" />
31                    </params>
32                </rule>
33            </rules>
34        </property>
35        <property name="VerifyPassword" desc="Verify Password">
36            <rules>
37                <rule type="required" contexts="Register,Update" />
38            </rules>
39        </property>
40        <property name="FirstName" desc="First Name">
41            <rules>
42                <rule type="required" contexts="Update" />
43            </rules>            
44        </property>
45        <property name="LastName" desc="Last Name">
46            <rules>
47                <rule type="required" contexts="Update" />
48                <rule type="required" contexts="Register">
49                    <params>
50                        <param DependentPropertyName="FirstName" />
51                    </params>
52                </rule>
53            </rules>            
54        </property>
55        <property name="LikeOther" desc="What do you like?">
56            <rules>
57                <rule type="required" contexts="Register,Update"
58                    failureMessage="If you don't like Cheese and you don't like Chocolate, you must like something!">

59                    <params>
60                        <param ServerCondition="getLikeCheese() EQ 0 AND getLikeChocolate() EQ 0" />
61                        <param ClientCondition="$(&quot;[name='LikeCheese']&quot;).getValue() == 0 &amp;&amp; $(&quot;[name='LikeChocolate']&quot;).getValue() == 0;" />
62                    </params>
63                </rule>
64            </rules>            
65        </property>
66        <property name="HowMuch" desc="How much money would you like?">
67            <rules>
68                <rule type="numeric" contexts="Register,Update" />
69            </rules>            
70        </property>
71        <property name="AllowCommunication" desc="Allow Communication">
72        </property>
73        <property name="CommunicationMethod" desc="Communication Method">
74            <rules>
75                <rule type="required" contexts="Register,Update"
76                    failureMessage="If you are allowing communication, you must choose a communication method.">

77                    <params>
78                        <param DependentPropertyName="AllowCommunication" />
79                        <param DependentPropertyValue="1" />
80                    </params>
81                </rule>
82            </rules>            
83        </property>
84    </properties>


Easy to Follow OO Design Posts? - Follow Me

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.

ValidateThis! - Server Side Validation Architecture

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.


ValidateThis! - Object Oriented Validations Demo Now Online

I have put together a demo of my validations framework for ColdFusion that I have been working on for the past several weeks. It's available here. The demo shows how the framework can take a simple xml file, which describes the business rules for an object, and generate client-side and server-side validations on the fly. It is a proof-of-concept, running in an environment identical to that which would be used in a real application. It is a simple, one-page example, but is utilizing Coldspring and Transfer behind the scenes.

From the demo page one can view the xml file that is being used to drive all of the validations. The schema for this file is still a work in progress, but it provides some insight into how one would implement the framework. Note that the schema itself is somewhat irrelevant, as the framework is designed to accommodate any schema, as long as it contains the expected metadata. Also, as a result of a conversation I had with Matt "I hate xml" Quackenbush, I have added the ability to define validations using ColdFusion code inside either your business object or another object injected into your business object. This is not something that I'd probably use, but I was led to believe that there are those out there who would appreciate not having to write an xml file to define their validations.


Previous Entries / More Entries