ValueObject Grind

The backend developer is done, and loads of CFC’s are freshly down from Subversion for my perusal. Since I’m using Cairngorm for this Flex 1.5 project, I do a series of enapsulated steps to tie my front-end to the back.

  1. Open his CFC’s, find a method I need, and write a business delegate for it
  2. write a Command to launch the Delegate, and post it’s data on the ModelLocator
  3. add the necessary command constant names for EventBroadcaster in the Constants & Event classes
  4. open up the CFC value objects that the back-end developer has done, copy and paste the variable names into a Value Object class, and finish the class
  5. Since we are using ColdFusion pre-7.0.x, we can only get generic transfer objects back from the server (unlike AMFPHP or OpenAMF). So, we have a Factory class create Value Objects from the Transfer Objects ColdFusion sends back in the Delegate. I write the methods to create them as well as give back arrays of them.

…this is where things start to suck. It’s not hard; you just convert uppercase property names to camel-case’d Value Object class property names like so:

public static function getUserVOFromUserTO( p_to : Object ) : UserVO
        var user : UserVO = new UserVO();
        user.firstName = p_to.FIRSTNAME;
        user.lastName = p_to.LASTNAME;
        user.userID = parseInt ( p_to.USERID );
        return user;

However, our value objects have a lot more property names, some have arrays of other vo’s they link to, and we have a lot more value objects since this is an extremely large project.

Hard? No. Tedious? Damn straight… It is extremely important we get strong-typing to ensure the data we are using is correct and easier to debug if we find a problem. Using a for loop in the above with a toLowerCase() could work, but then you are assuming that data sent from the back-end is correct. Even worse, while CFC VO’s are somewhat easy to read since most properties are up top, some have linkages with other items (because of linked tables, many to one relationships, etc.), thus you cannot necessarely view it as a 1 to 1, CFC to client side VO relationship.

A monkey could do this shit. That’s the rub; most programmers who make money start to recognize long, repetitive tasks, and the first question they ask themselves is, “Can this be automated?”.

Flex 2? Sure, right click on a CFC, generate ActionScript VO. Flex 1.5 using ColdFusion >7.0.x? Nope, not without sacrificing strong-typing. You can get away with that in smaller scale apps, but not enterprise applications.


…speaking of monkey’s, maybe I could teach a Bathroom Monkey to code VO / TO conversion functions… hrm…

My manager says writing CRUD operations is worse (which is automated in Flex 2 as well btw for ColdFusion). I certainly don’t evny the back-end guys, and will happily make VO’s in this Factory all day and smile when I think of what they most go through.

BTW, I’ve unsubscribed from the 10 billion email lists I was on, so if you don’t see me answering questions, it’s because I am not receiving any emails (Flashcoders, Flexcoders, etc.). I need a break from lists.

2 Replies to “ValueObject Grind”

  1. Man–you are a machine! I must admit I’m slightly happy to see you take a break from the mailing lists–I am in constant awe / amazement at how you seem to be busting ass on projects and slinging down replies on the lists simultaneously. Peace out.

  2. Jesse, XDoclet is a good way of relieving the tediom associated with code-generation; we’re creating a lot of our value objects on Flex 2 / Cairngorm projects this way, and I wonder if you might be able to mash it around a bit for CFCs ?

    One of our tech architects, Peter Martin, blogged about this here – let me know how you get on with applying this to CFC if it works for you:



Comments are closed.