Posted At : November 12, 2008 10:59 AM
| Posted By : Bob Silverberg
Related Categories:
Transfer,ColdFusion,OO Design,How I Use Transfer
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]
Posted At : November 3, 2008 11:49 PM
| Posted By : Bob Silverberg
Related Categories:
ColdFusion,Transfer,OO Design
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.
Posted At : October 14, 2008 2:27 PM
| Posted By : Bob Silverberg
Related Categories:
ColdFusion,ValidateThis!,Transfer,OO Design
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]
Posted At : October 6, 2008 11:41 AM
| Posted By : Bob Silverberg
Related Categories:
ColdFusion,ValidateThis!,Transfer,OO Design
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]
Posted At : August 22, 2008 7:43 AM
| Posted By : Bob Silverberg
Related Categories:
ColdFusion,Transfer
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]
Posted At : August 20, 2008 8:54 AM
| Posted By : Bob Silverberg
Related Categories:
ColdFusion,Transfer
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.
Posted At : July 27, 2008 4:49 AM
| Posted By : Bob Silverberg
Related Categories:
Transfer,ColdFusion,OO Design,How I Use Transfer
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]
More Entries
