Bob's Blog

Just a quick note to announce the release of version 1.1 of ValidateThis, an awesome validation framework for ColdFusion. This version includes one new validation type, notRegex, which was contributed by John Whish, and a bunch of small fixes, contributed by Greg Moser.

For those of you reluctant to use a 1.0 version of anything, now that we've got 1.1 out the door you can grab it and give it a try! Here are some resources that will help you:

• The main home of the framework is www.validatethis.org, which includes an online demo and links to all of the following.
• The framework can be downloaded from the ValidateThis RIAForge page.
• Online documentation is available at www.validatethis.org/docs.
• API documentation is available at www.validatethis.org/docs/api.
• There is a Google group available for asking questions, making suggestions, and general discussion at groups.google.com/group/validatethis.
• The source code is hosted at GitHub, and contributions are always welcome.

So what's stopping you? Go download the latest and greatest version of ValidateThis and take it for a spin!

I am pleased to announce that ValidateThis, an awesome validation framework for ColdFusion, has finally gone gold! That's right, version 1.0 of the validation framework that you've come to know and love is in the wild. While I'm proud of the framework, I'm even prouder of the number of developers who contributed to this release. In addition to me, the following people made a contribution:

• John Whish
• Chris Blackwell
• James Buckingham
• Dustin Martin
• Marc Esher
• Jamie Krug
• Seb Duggan
• Mike Henke
• Adam Drew

Most of went into this release won't be noticeable to the developer, or at least won't affect the way you interact with the framework. Here's a quick summary of the changes in this release:

• Upgraded to the latest version of the jQuery Validation plugin, which replaces jquery.validate.pack.js with jquery.validate.min.js. If you are loading this file yourself (as opposed to using a CDN, which the framework does by default), then you should replace that file.
• The default generated failure messages are now identical on the client and server, and are based on information in a resource bundle. This means you can easily change the default generated failure messages if you wish, and the changes will be reflected on the client and the server.
• Thanks to John Whish (who I have unilaterally appointed as client-side-czar for the framework) the Javascript that is generated has been greatly improved. Many of the changes that John made were based on suggestions from Dan Switzer.
• You can now store your definition files in a folder structure that mirrors a dot-based naming scheme for components.
• You can now instruct the framework to ignore missing properties in your objects, as opposed to throwing an exception if a property is missing.
• A new config option has been added: vtFolder which you only need to use if the framework resides in a folder that isn't called ValidateThis and you are on a case-sensitive system.

The biggest change is the second one mentioned above: the default generated failure messages. If you are currently using the i18n capabilities of the framework this may affect you, so I suggest you read the i18n information available in the online documentation.

If you've been holding off checking out the framework until it reached version 1.0 (silly people), now's the time to get cracking. Here are some resources that will help you:

• The main home of the framework is www.validatethis.org, which includes an online demo and links to all of the following.
• The framework can be downloaded from the ValidateThis RIAForge page.
• Online documentation is available at www.validatethis.org/docs.
• API documentation is available at www.validatethis.org/docs/api.
• There is a Google group available for asking questions, making suggestions, and general discussion at groups.google.com/group/validatethis.
• The source code is hosted at GitHub, and contributions are always welcome.

So what's stopping you? Go download the latest and greatest version of ValidateThis and take it for a spin!

I promised John Whish that we'd have another version of ValidateThis, an awesome validation framework for ColdFusion, out in time for his presentation at Scotch on the Rocks on March 4th, 2011, and I've never been one to disappoint. So today I announce the release of version 0.99 of ValidateThis.

The lion's share of the work on this release was done by John, Adam Drew and myself. A lot of the work in this release is actually building towards something very cool that will come out later in the year, but there are still some significant enhancements including:

• Goodies for ColdBoxers including a ColdBox interceptor and three new sample applications.
• New debugging features to make it easier to figure out what's going wrong when things aren't working as you expect.
• The ability to ignore a validation client-side.
• Support for onMissingMethod in your objects.
• JavaScript assets are now retrieved from a CDN or written to the browser so you don't need to place JS files in a web accessible folder.
• Updates to the addFailure() method.
• A couple of new validation types were added.

As always, the latest version can be downloaded from the ValidateThis RIAForge site. Details of the enhancements follow:

[More]

I did an impromptu presentation for the Dallas / Fort Worth ColdFusion User Group a couple of days ago, filling in for someone who was supposed to present on ValidateThis but was unable to make it to the meeting. I delivered the presentation that I gave at both cf.Objective() and CFUnited last year.

Dave Shuck was kind enough to record the presentation and make the recording available, so if you're interested in watching it you can do so. I will warn you that the recording is around 90 minutes long because I tended to talk quite a bit throughout the presentation (as it was an informal preso), although I do believe that most of the information I was providing was useful.

If you do watch the presentation and have any questions about ValidateThis please feel free to send your questions to the official ValidateThis Google Group.

I'd like to thank Dave and the DFWCFUG for giving me the opportunity to present to them. If any of you are UGMs and are looking for a remote presenter I'm always available and interested, and can present on a number of topics.

In addition to a bunch of neat new features, version 0.98 of ValidateThis also included a number of new validation types. One of the most important aspects of the framework, to me anyway, is the fact that it is incredibly extensible and allows you to easily create your own validation types, which is precisely what a number of folks including Adam Drew, Marc Esher and Chris Blackwell did. They were also kind enough to contribute those validation types to the framework so we can all benefit from them. In this post I'll describe each of the types that were added for version 0.98.

Each validation type accepts certain parameters, all of which have been documented in the ValidateThis Online Documentation, so I won't clutter up this post with that information. You can click on the name of each type in this post and be taken directly to its description in the docs if you wish. I'll just concentrate on describing what the validation type tests and suggestions for ways in which it might be useful.

[More]

As a follow-up to my post announcing the availability of version 0.98 of ValidateThis, which just included a brief summary of the new features, this post will describe some of those features in more detail.

defaultFailureMessagePrefix Configuration Option

When a validation fails the framework adds a failure message to the Result object that is returned to you. Each validation type has a default failure message, and you also have the option of overriding the default failure message using the failureMessage attribute of the rule element. The default messaged generated by VT are customized based on the type of failure and any parameters that were in place for the rule. For example, if a rule of type email which is defined on the emailAddress property of your object fails, the message will read "The Email Address must be a valid email address." If you've defined a rule of type rangeLength with a minLength of 5 and a maxLength of 20 on the password property of your object, the default failure message will read "The Password must be between 5 and 20 characters.

[More]