Bob's Blog

Update: The information in this post is no longer correct due to changes to the framework. A new series is available via the Getting Started with VT category of my blog.

Original content of the article follows:

In the next few posts in my series about getting started with Transfer and ValidateThis!, my validation framework for ColdFusion objects, we're going to take the simple sample application that was described in the previous post and add some server-side validations to it, using VT of course. That will involve two steps:

• Integrate ValidateThis! into our Business Object.
• Use the framework (via our Business Object) to perform server-side validations and make use of the results returned by the framework.

This post will cover the first step, integrating the framework into our Business Object. To do that we're going to have to make the following changes to or sample app:

• Import the bean definitions for ValidateThis! into our Coldspring config.
• Add a ValidateThisConfig bean to our Coldspring config.
• Add a TDOBeanInjectorObserver bean to our Coldspring config.
• Add a decorator for our User object.

That may sound like a lot of work, but it mostly involves copying boilerplate into existing files. Let's get started by importing the bean definitions for ValidateThis! into our Coldspring config. We're going to add the following line to our Coldspring.xml file:

That will give our Coldspring bean factory access to all of VT's beans. Now we can add a ValidateThisConfig bean to our Coldspring config:

This sets a number of default values that VT will use. I explained what these entries do in the Release Notes for version 0.6 of VT, so I won't go into it again here. For the sample app the above values will work. Next we need to add a bean definition for the TDOBeanInjectorObserver:

This sets up Brian Kotek's Transfer Decorator Object Bean Injector Observer (which can be found at his ColdSpring Bean Utilities RIAForge project). In a nutshell that component will allow us to inject other components into our Transfer objects when they are created. Note that the TDOBeanInjectorObserver as well as the generic beanInjector both ship with the VT framework, so if you aren't already using them you don't need to worry about downloading or installing them. If you are already using the TDOBeanInjectorObserver in your application then you won't need to add that bean definition at all. Note also that the constructor-arg afterCreateMethod is being set to "setUp" - we'll come back to that in a bit.

OK, now that our Coldspring setup has been done we can move on to adding a decorator for our User object. To tell Transfer that we want to use a decorator for the User object, we need to make a small change to our transfer.xml file:

You'll notice that all we've done is added the decorator="model.user" attribute to the User object definition. Now we need to create that decorator, so we'll create a file called user.cfc and place it in the /model directory. Here's what that file will contain:

Hmm, you may be saying, there's nothing in there. That's true. The fact is that all of the code that you need to add to your object's decorator in order to integrate VT into your object is the same no matter what your object is. The code will be identical in your User object, your Account object, your Product object, etc. So in order to avoid having to repeat that code over and over again, we're going to create an Abstract Transfer Decorator object. You might have noticed that the User decorator shown above does in fact extend another cfc, called AbstractTransferDecorator, so that's where we're going to put the actual integration code. Let's look at that next:

OK, so there's a bit of code there, but the nice thing is that, if you just want to use the framework, you don't really need to understand exactly what it's doing. You can just copy that code as is into your abstract decorator and you're good to go. Of course, if you're already using an abstract decorator you'll have to make sure that none of those methods conflict with any existing methods. For example, if you already have an onMissingMethod() handler in your abstract decorator you'll need to integrate the code above into your existing method. In the interest of keeping these posts short and to the point I'm not going to elaborate on what it's doing right now, but I will discuss it in a future blog post.

At this point we're actually finished integrating the framework into our business object. We're now ready to use it. Hmm, that was even less painful that I imagined ;-)

In my next post I will discuss the changes that we need to make to the sample app to make use of the framework to perform our validations.

A zip that incorporates all of the code changes described in this post is attached.