Bob's Blog

I have been working with my own validation framework, which I've named ValidateThis! (VT for short), for the past several months, and thought that it was time to talk about it some more, and provide some guidance to anyone who is interested in giving it a try. To that end I'm going to start a series about getting started with ValidateThis, specifically discussing using it to add validation behaviour to Transfer objects. The framework has been developed to allow for integration into any model that uses business objects, so Transfer is not a requirement to make use of VT, but as an example of integration with Transfer has already been done it seems like a sensible place to start.

As I haven't written about VT for quite some time I'll start with a brief introduction to VT and then move on to a practical guide to using VT with Transfer.

What is it?

VT is a set of ColdFusion components which enable a developer to add validation "smarts" into their Business Objects. The developer defines all of the validation business rules for an object in an xml file, and VT then automatically translates those into both client-side and server-side validation code. There is a lot more to it than that, but that is the foundation of what it does. If you want to see a demo of it in action, check it out at www.validatethis.org.

[More]

I want to talk about object inheritance, which may sound a bit enigmatic, so I'm going to start with an example:

Let's say I have a number of types of Employees that I'm trying to model. I have Developers, who have attributes such as favouriteLanguage and enjoysDeathMetal and behaviours such as code() and test(). I have Designers, who have attributes such as favouriteColour and toleratesDevelopers and behaviours such as makePretty() and makePrettier(). And I have Analysts, who have attributes such as levelOfAttentionToDetail and totalPagesOfRequirementsProduced and behaviours such as ask() and tell().

In addition to those specific attributes and behaviours, all of these employee types also share some common attributes, such as userName, firstName and lastName and also have common behaviours such as startDay(), takeBreak() and askForRaise().

This is an example of inheritance, a form of one-to-one relationship. We can say that a Developer is an Employee, a Designer is an Employee and an Analyst is an Employee. It is not an example of composition. We would not say that a Developer has an Employee or that an Employee has a Developer. The terms that are commonly used to describe this relationship between classes are Supertype and Subtype. Employee is a Supertype, while Developer, Designer and Analyst are all Subtypes of Employee.

So, the question is, how do I implement this model using Transfer?

[More]

I left something critical out of my last post about how I'm using Transfer (an ORM for ColdFusion) these days.

If you've been following along you'll know that I'm using an Abstract Transfer Decorator, which all of my concrete decorators extend, and that I'm using Brian Kotek's most excellent Bean Injector to load singletons into my Transfer objects. This raises an interesting issue: How to inject the appropriate Gateway Object into my Transfer Object.

[More]

I've been meaning to follow up on my How I Use Transfer series, as I've made a few changes to the way I write my ColdFusion code since that series was written. One of the biggest changes was to encapsulate all database access in my Gateway components.

Now I say biggest not because it took a lot of time and effort to make the change, in fact the opposite is true. I say biggest simply because it represented a significant shift in the way I'm designing my model. Let me start with the rationale for making this change.

[More]

There have been some postings recently about the state of the ORM landscape in ColdFusion, and while I have found this conversation interesting, I have not found it particularly useful.

There exists a group of ColdFusion developers, myself included, who would like to improve the way that we write and structure our code. We have been encouraged to adopt a more object oriented approach to our development, and I, for one, have found it to be of great benefit.

One of the things that has made this transition easier for me is the existence of these "ORMs" for ColdFusion. I started off with Reactor, and now use Transfer, and I have found that not only do these "ORMs" do a lot of the more menial tasks for me, but they also encourage me to "think in objects". Sure, the objects that I'm working with are closely tied to the physical database structure, but they're still objects. I still get the benefit of encapsulation, and through the use of Transfer decorators I feel that I am able to give my objects meaningful behaviour, thereby creating rich business objects.

I know from experience that when a developer is starting down this path it can be quite daunting, and we often look to those with more experience than ourselves for guidance. I hope that someone in that boat would not be "turned off" the existing set of "ORMs" for ColdFusion because they are not considered to be true ORMs.

This brings me to the title of this post, which was inspired by a post by Peter Bell. I find Transfer to be an indispensable tool for building OO-like applications with ColdFusion, and can only encourage people to investigate and use it. It may not be a true ORM, but that doesn't make it any less useful. Let's not throw the baby out with the bath water.

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]