Tripping On The Beans

Today I got a little time to hop back on my journey to OO and Model-Glue enlightenment. It's difficult to keep focused on this project because [insert standard I'm really busy excuse here]. Anyhow, I'm a little tripped up and I'm going to lay out my experience here for the sake of documenting my learning.

Here's the deal. I'm working with a simple user management module in my application. The code that I'm using is generated by the Illudium code generator. While I don't expect the code to be in final working code 'out of the box' (what box?) I have been pleasantly surprised with how workable it truly is. So here's my dilemma. I have a simple user bean that I'm using to capture the form inputs and pass to the userDAO. Let me side step for a moment for the sake of beginners and give a quick explanation of beans and DAO's. I'm going to quote from Doug Boude's lexicon entitled OO Terms In a ColdFusion Context.

Doug defines a bean as:

You can first off think of a bean as a small, solo object. It's somewhat simple, as objects go, and has no other purpose in life than to store a collection of related values, and the means to get and set them. For example, we have a User bean. It stores the values Firstname, Lastname, Age, Sex, and IQ. We are never allowed to DIRECTLY change or retrieve the bean's values, and can only do so using the bean's SETTER and GETTER methods, like so:

[cfscript]

myUser = CreateObject("component","UserBean");

userIQ = myUser.getIQ();

//change the IQ a little...

myUser.setIQ(userIQ + 10);

[/cfscript]

And a DAO as:

When you hear or read the acronym 'DAO', always think "database actions dealing with a single record". DAO is one of the three "Model sisters" (the other two are Gateway and Record (who also holds the nickname "Bean" in some circles)), and is a CFC that contains a collection of basic functions to allow one to create, read, update, and delete a single record in a database table. If your app needs to perform some action on a single record, create a DAO to help out with that task.

Another resource that I've just discovered but yet to really dig into is the ooGlossary.

Back to the topic. So my user form is pretty simple. My event handler gets the user bean and uses it to populate the form. Very nice for reusability. Essentially the same exact form can be used for adds and edits. The tricky part comes in with an add. With an empty bean comes an empty userId. Which doesn't work so good with a required element. Obviously I have to tweak something somewhere to make the add happen. The first thought that I had was to do something like this in my user form.

And then use #userId# to populate the form field. Something about this just doesn't feel right. I don't really think it's good form to go messing with the bean. Anyhow, I rolled with it just to see what would happen. So my controller took the user bean and passed it along to my user service which in turn was ready to happily serve that bean to my DAO to commit the data to my database. Unfortunately I stumbled upon the following MG error.

Very weird. Now hear me out here. Granted I am using generated code and I do not expect it to be perfect, but it appears that MG is actually stricter then CF when it comes to data types. So since my database datatype was varchar(35) to accommodate the UUID the code generator gave me a CF datatype of string. MG noticed that the userId that I passed was a UUID and stopped me dead in my tracks. Isn't a UUID also technically a string? CF would have gladly allowed the data to pass but not in MG. This occurrence as well as my earlier bad feeling about manipulating the userId on the form side of things lead me to rethink.

My thought track is now moving to my user bean component. I'm thinking of changing my setuserId() function to default the userId to #createUUID()#? Should I be changing all the userId datatypes in the generated code to be a uuid datatype? I'm not quite sure. I'm not specifically asking those reading to help but please feel free to offer up an opinion if you have one. I'm mainly trying to document the learning process to hopefully aid others in the thought process.

Comments (5) | Print | Send | Code | del.icio.us | Linking Blogs | 2846 Views