Bob's Blog - ColdFusion Tidbits - Transfer

Getting Started with VT - Adding Validation Behaviour to Transfer Objects

Wed, 04 Mar 2009 16:20:00 -0400

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]

Single-Table Inheritance with Transfer

Tue, 27 Jan 2009 19:53:00 -0400

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]

How I Use Transfer Today - A Gateway MapFactoryBean

Mon, 24 Nov 2008 16:33:00 -0400

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]

How I Use Transfer Today - Encapsulating Database Access

Wed, 12 Nov 2008 10:59:00 -0400

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]

I Don't Care What An ORM Is!

Mon, 03 Nov 2008 23:49:00 -0400

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.

ValidateThis! - Server Side Validation Architecture

Tue, 14 Oct 2008 14:27:00 -0400

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]

ValidateThis! - An Object Oriented Approach to Validations

Mon, 06 Oct 2008 11:41:00 -0400

I have written in the past about the approach I take to building an object oriented model layer for my ColdFusion applications. For the most part I was happy with the way I designed things and the code that I wrote. There was one area, however, that I was never really that pleased with; validations.

So I spent the past several weeks working on a whole new approach to doing validations, and I am now ready to share it with anyone who is interested. Because I intend for this to become a standard tool in my development toolset, I am going to refer to it as a Validation Framework. I'm not sure if that is an appropriate use of the term, but it's my code and my blog, so that's what I'm going to call it.

I had the following goals for my validation framework: [More]

Easy Access to Primary Keys in Transfer Objects

Fri, 22 Aug 2008 07:43:00 -0400

I just added a couple of new methods to my AbstractTransferDecorator to make some of my ColdFusion development tasks easier. I found that when trying to write abstract code I needed to know the name of the primary key column of my object, and also sometimes needed to know the value of that column for the current object. So I wrote two new methods to address those needs:

__getPKColumn() - Returns the name of the id column for the current object.
__getPKValue() - Returns the value of that column for the current object.

I chose to prefix the method names with a double underscore so I wouldn't end up overwriting the getters if any of my objects ever have those names as properties. Although I'm fairly certain that would never happen it seems like a good idea nonetheless. Here's the code: [More]

Transfer's getMemento() has Changed

Wed, 20 Aug 2008 08:54:00 -0400

Although I have been fairly vocal about the fact that the getMemento() method available from Transfer (an ORM for ColdFusion) is undocumented and subject to change, and have even written my own implementation of it in my AbstractTransferDecorator, I discovered today that I am still calling it one place in my ColdFusion application code (which I wrote a long time ago). And that one line of code is now throwing an error. I understand from some comments on Jason Dean's blog that the internal implementation of mementos did change recently, in Transfer 1.1 according to Mark Mandel, which explains my problem.

I just thought it would be worth sharing this with the community, as I have a feeling that I'm not the only one to use getMemento() on occasion. So be warned: if any of your code uses getMemento() test it with the latest BER of Transfer as you may need to make changes to your code before deploying Transfer 1.1.

How I Use Transfer - Part X - My Abstract Transfer Decorator Object - Validations

Sun, 27 Jul 2008 04:49:00 -0400

In the previous post in this series about Transfer (an ORM for ColdFusion) I discussed the populate() method of my AbstractTransferDecorator. Having discussed some of the simple methods of this object in the post prior to that, what remains is a discussion of how I'm currently using this object to do validations.

There are three methods in this object that are used to support validations in my apps:

getValidations() - This returns an array of business rules that apply to the Business Object.
addValidation() - This is a helper method to make defining validations simpler.
validate() - This contains generic validation routines that are shared by all Business Objects.

Let's start with getValidations(), which returns an array of business rules. This array does not include any information about implementing those rules, it simply describes the rule, and any requirements for the rule. For example, one rule might be Required, which simply means that the user must enter a value for the property. Another rule might be Range, in which case the array item would also include the upper and lower limits of the range. One of the nice things about this approach is that this array can be used to generate both client side and server side validations. So I only have to describe the validations for a given object once in my app, and then I have additional pieces of code which take these rules and automatically generate the JavaScript required for client validations, and the CF code required for server side validations. We'll see an example of the latter when we discuss the validate() method later in this post. [More]

How I Use Transfer - Part IX - My Abstract Transfer Decorator Object - The Populate Method

Tue, 22 Jul 2008 10:44:00 -0400

In the previous post in this series about Transfer (an ORM for ColdFusion) I introduced my AbstractTransferDecorator and discussed some of its simpler methods. In this post I want to go through the populate() method in detail. I have posted bits and pieces of this method in the past, but I don't think I've ever documented the whole thing, as it stands today. I'll break it into pieces to make it a bit more manageable.

[More]

How I Use Transfer - Part VIII - My Abstract Transfer Decorator Object - Simple Methods

Mon, 21 Jul 2008 12:11:00 -0400

In the past two posts in this series about Transfer (an ORM for ColdFusion) I discussed how I have implemented my Abstract and Concrete Gateways. As you may recall from Part II, that leaves my AbstractTransferDecorator Object as the final abstract object in my model. There is a lot of code in this object, and I plan to provide a lot of explanation, so I'm going to break this up into a few posts.

My AbstractTransferDecorator acts as a base object for all of my Concrete Decorators, and, because most of my Business Objects are created for me by Transfer, it really acts as an Abstract Business Object. For a basic overview of what a decorator is, and how one is used with Transfer, check out this page from the Transfer docs.

I have blogged about this object a few times before, but the posts in this series will, for now, supercede all of those previous posts, as this object continues to change. In fact, this object has a few methods and techniques the design of which I'm not crazy about right now. There will definitely be changes coming, at some point down the road. [More]

How I Use Transfer - Part VII - A Concrete Gateway Object

Tue, 15 Jul 2008 13:27:00 -0400

In the previous post, I described my Abstract Gateway Object. As I did with the Service Objects, I'm going to take a moment to describe a Concrete Gateway Object as an illustration of how I use the Abstract Gateway. I'll start with a recap of the differences between the Abstract Gateway and Concrete Gateways, followed by a look at the code of a specific Concrete Gateway.

The Abstract Gateway Object

Is never instantiated as an object.
Cannot be used as is.
Is only ever used as a base object for Concrete Gateway Objects.
There is only one Abstract Gateway Object, called AbstractGateway.cfc.
Does not have any Transfer classes associated with it.

Concrete Gateway Objects

Are instantiated as objects.
Methods on them are called by Service Objects.
All extend AbstractGateway.cfc.
There are many Concrete Gateway Objects, e.g., UserGateway.cfc, ProductGateway.cfc, ReviewGateway.cfc, etc.
Have one "main" Transfer class associated with them, but can interact with others via code specific to the Concrete Gateway.

One thing to note here is that my Gateway Objects are all injected into Service Objects via Coldspring, and are only called by Service Objects. So the Service acts as an API to the entire model. If a Business Object needs to call a method on a gateway, it calls it via a Service Object that is injected into the Business Object. [More]

How I Use Transfer - Part VI - My Abstract Gateway Object

Mon, 14 Jul 2008 06:35:00 -0400

In the past few posts in the series I discussed, at length, how I have implemented my service layer, which consists of an Abstract Service Object and Concrete Service Objects. I decided to take it easy this time around and just look at my AbstractGateway Object, as it's pretty simple in comparison.

As with the AbstractService, this object is not meant to be instantiated on its own, but rather acts as a base object which my concrete Gateway Objects extend. There are only three public methods in my AbstractGateway:

GetList(), which returns a listing for the default entity
GetActiveList(), which returns a listing for the default entity, but only includes Active records
ReInitActiveList(), which is used to reinitialize the cached query for the Active List (see below for details)

[More]

How I Use Transfer - Part V.1 - A Comment and Response

Tue, 08 Jul 2008 10:28:00 -0400

Brain Kotek wrote a lengthy and informative comment to my last blog post. I started composing a response as a comment of my own, but it got very long, and I think that both Brian's comment and my response contribute greatly to the series, so I've turned my response into a blog post. I'm including Brian's comments in quotes throughout this post.

[More]