My next stumbling block on my journey is the creation and persistence of application level data. Specifically the DSN for my application. Don't worry, when I get over these initial stumbling blocks I'm sure everything will run a lot smoother, but I keep sharing these items for a simple reason. I think these little things are the kind of things that trip up a lot of folks when trying to adopt new concepts and frameworks. I myself have let little things like this discourage me and I move on to things that are familiar and comfortable and forget all about the learning that I had done.

A few follow-ups from yesterday's post. First off, Brian noted that his generator will recognize char(35), assume a UUID and generate the code accordingly. This worked perfectly and is definitely appropriate as Brian pointed out to me because since UUID's are fixed length and do not require unicode support.

Another error on my part in that post was pointing out that MG is stricter with datatypes then CF. This is not true. I was passing the entire userBean to the saveuser() function in my service when all I really needed was to pass the fields themselves (which I accomplished by using the beans getMemento() function) as an argument collection. I'm assuming that is an appropriate use of that function since it returns a struct containing each value. Therefore Model-Glue was trying to evaluate my component as a string which obviously don't work ;)

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.

In my last post in the Project Learn series I installed the cfcPowerTools code generator. My intention was to fully evaluate the tool and provide an objective review of it's functionality. Unfortunately something happened that has changed that plan. I had a nice quiet house to myself all day Sunday so I decided to do a little more research in my framework quest. I decided to sniff a little glue. That's right, Model-Glue. I have mixed feelings about this decision, but I'm pretty sure that my mind is made up about it. In this post I'll try to lay out some of the factors that influenced this change of heart.

One of the biggest barriers to my learning a framework was a general lack of knowledge of OO. To be honest, in all of the research that I have done regarding frameworks I never really felt intimidated about learning the framework itself. After all, a framework is really nothing more then a structured and documented way of organizing your code and templates. Sure there is a little more to it then that, but learning new tags and functions and methodologies is not really all that difficult. Learning how to implement beans and DAOs and gateways and tying those in to the framework seems to be the challenging part. So what does any of this have to do with Model-Glue and how does that make MG better then Mach ii? Well, it doesn't have anything to do with it really and I can't really say that one framework is better then another at this point. The bottom line in my decision was that the documentation and community discussions surrounding MG seemed to be more OO focused.

I started reading Dan Wilson's series on MG:Unity series and things just started clicking for me. I've read Ray Camden's series before but I'm not sure I really had enough background at the time that I read it to grasp everything that he laid out (and that's no fault of Ray's - his series is very well written and easy to follow). Dan's series has been very helpful to me this time around. I'm still feeling a little intimidated by all of this but I feel much more confident then ever now. Dan's series focused on integrating and utilizing MG's built in ColdSpring support. He does a good job laying the OO groundwork and showing how to build the MG application from the ground up. The amazing thing to me is the feeling I'm getting that leveraging this framework will lead to extremely rapid application development. I'm not sure if this is a misconception - I'll obviously answer that question for myself as I continue in my learning.

As a side note, Dan's series recommends using the Roobios code generator. For my learning I've decided to stick with Brian Rinaldi's Illudium code generator to do the dirty work for me. There are a few reasons I made this decision and a few of them have to deal with Brian himself. First of all, I don't want to waste any more time evaluating anything else. Secondly, Brian is a really good dude who has been very helpful to me in answering questions and explaining a lot of these concepts to me so I want to support his tool and help him get some exposure with it. Thirdly and most importantly, I really liked the format of the code produced by his tool. It feels easy to work with to me. From what I've done so far with MG the code his tool has produced for me has integrated well.

I don't think there is a need for me to formally document the learning process of MG as Ray and Dan have, but I will definitely be sharing my experiences as I continue along with it. As others have said, I'm definitely sniffing the glue.

The next step in Project Learn is to evaluate another code generator. This blog post will focus on installing cfcPowerTools, a tool created by Tom Schreck. I'll quote a little from the tool homepage (which is a very nice page by the way - complete with an actual online working demo of the tool):

cfcPowerTools is a productivity tool used to jump start your development effort. cfcPowerTools is a code generator that offers the following:

• generate CFCs from database tables
• generate database table from CFC
• batch generate CFCs from multiple database tables
• generate HTML, FLASH, and XML data entry forms
• supports round trip editing
• getter/setter generation

Like the Illudium generator, cfcPowerTools comes with different templates that can be used for generating your code. The following templates come standard:

• Model Controller
• MACH II
• Concrete
• Simple
• Default

A few differences from the Illudium generator are apparent before even downloading the tool. The first difference is that cfcPowerTools allows for 'managed' code blocks. The blocks are flagged as such and can be regenerated at any time. The second noticable difference is support for mass generation from multiple tables. This would certainly be a timesaver (and something that I'm positive Brian could easily add to his tool).

On to the installation. Like the Illudium generator the install is very easy. Just download the project and unzip to your webroot. No configuration is needed since cfcPowerTools utilizes the ColdFusion admin API - but obviously you'll need your admin password handy. Hit the tool in your favorite browser and enter your pass. That's it.

In my next post will get into the tool and create some code.

In the last post in the Project Learn series we installed the Illudium PU-36 Code Generator. This post will go into a little more detail and we will actually get into generating some code.

Before I get started I should give a quick mention that the actual application that we will be building in this series will be an extremely simple Content Management System (CMS). Essentially the system will have a users table, a pages table and a few other miscellaneous tables (tables for links, link targets, etc). I figured this would be the easiest way to dig into the code generators and framework while still being something that is actually a (hopefully) usable end product.

So the first post in my series will focus on installing the first code generator that I plan on evaluating. The Illudium PU-36 Code Generator by Brian Rinaldi. Rather then try to creatively come up with a better description then Brian's I'll just quote the description from the project page:

This project generates ColdFusion components (i.e. bean, DAO, gateway, service), ColdSpring XML, Transfer XML, and ActionScript Value-Objects using the admin api and database introspection. The front-end is built in Flex 2. The code outputted for easily pasting or saving into a project to allow you to get a headstart on some of the gruntwork of doing OO in CF. It uses XSL to generate the components and is designed to allow you to easily add to or modify the generated code. You can even create new templates that can be swapped out at run-time.

The first step is to download the tool. There are two options - vanilla (HTML) or chocolate (Flex - yummy). (OK, they're really not called vanilla and chocolate, but I'm taking some creative liberties). I've checked out both versions before - very briefly mind you - but for this go 'round I'm going with the super sexy Flex version.

Step 2 isn't much harder - install the generator. Again I'll quote from the project page:

1. Copy the contents into a directory name "cfcgenerator" under your web root

NOTE: If you need to place it elsewhere, a mapping should work, but you will need to edit your webroot\web-inf\flex\services-config.xml and set true

1. Set your ColdFusion administrator password as the value of adminPass in Application.cfm

2. That's it!

There was one minor tweak I had to make to get the flex generator to run. The Flex version zip is packaged as /cfcgeneratorFLEX - but some of the createObject calls point to /cfcgenerator. A simple global find and replace on cfcgeneratorFlex (and change the name of the root folder) seems to do the trick. I've filed a bug on this.

So now the generator is installed. Simple stuff that's for sure. In my next post I'll talk about getting into the tool and generating some code.

Update: After talking with Brian it seems that the version that I obtained from Google Code was old - the new and most recent version is available at RIAForge. You can find it here: http://cfcgenerator.riaforge.org/

I'm in the midst of building my database structure for 'Project Learn' (see this post if you're not sure what that's about) and have come across the age old question: should I use auto numbered integers for my primary keys or should I create the id using createUUID() in CF and pass it in? I seem to go back and forth on this topic so I'll put my pro's and con's out here and leave it up to my readers for further discussion.

Pros to Auto Number:

1. Easy. Inserts will always handle the creation of the auto numbered id field.

2. Integers are more easily indexed by SQL server (performance related).

Cons to Auto Number:

1. Less control over data. I know this is kinda a 'control freak' thing, but I like to have control over the creation of the primary key so that I can pass that key back to my caller (or another function when cascading inserts such as a one to many type insert).

2. Related to Con #1 - have to rely on 'select @@identity' to return the most recently created id - which can be unreliable in a high traffic db. This topic has been debated many times and will likely continue to be. There are other ways to retrieve the id I believe - but I don't know much on this topic (anyone?).

Pros to createUUID():

1. As I stated above, I control the creation of the id and have no question that it is unique and the correct key.

Cons to createUUID():

1. No built in datatype in SQL for CF's UUID. Rob Gonda recently posted a way to create such a datatype so that you can validate this type so there's a workaround available for this con. 2. Non-integers are less easily indexed by SQL server.

So that's my dilemma. I'm also considering a mix of auto numbered id's and UUID pk's (using the UUID's where I need the granular control over the id number and the auto number where that's less important). I'd like to hear everyones opinion on this one. I'm really hoping that this series will be interactive and that as many people as possible feel comfortable joining in the learning and discussions. Feel free to tell me your thoughts.

So I'm going off the deep end and officially naming the series of blog posts and associated application development that I have began to undertake (I'm really not a geek, I swear!!). From now on this series will be known as 'Project Learn'. I chose this name because as I started to dig into this project today I realized that it's not only about a framework or methodology or tool or ideal - it's about all of those things and my documentation of the associated learning experience. I'm thrilled to be doing this since I think that I will do just as the project's name implies - learn a ton of new things. In fact I've already written up a few future blog posts based on just a few hours of development today. I really hope that anyone who wants to will feel free to participate in this series. Offer suggestions, opinions, ideas, counter-points. It's all about learning so keep it constructive and we'll have some fun. If you'd like to follow this series you can subscribe to the Project Learn RSS feed or just stay tuned to my blog.

About a week ago I blogged about a struggle I was having with choosing a framework. I've since done some more reading and chatting with folks and have made a few decisions. Despite the popular consensus I've decided to try to learn Mach-ii. The reasons I chose Mach-ii are simple: 1.) It looks the easiest to learn to me. I'm not sure if it's because the documentation/quick start guides are that well written or if it truly is the easiest framework to learn. 2.) I know a few really smart dudes that are big fans of Mach-ii and I think that they will really be cool in helping to answer any questions that I come across.

I've also decided to document my experiences on this blog. This series will probably be different from any "learn a framework" type series that you've come across before. I anticipate some bumps along the road as well as possibly some changes in direction along the way. I've mapped out a mental strategy with how I'm going to tackle this application and will outline it below. However I ask that you, the community, bear with me and share in my learning. If you have a constructive thought on any of the experiences that I share please feel free to comment. I'm a very open person when it comes to learning and I believe that we all have something we can learn from one another.

Here is my roadmap that I plan to follow (again, this is subject to (and likely may) change). My first step will be to build the DB structure. I then intend to use some sort of code generator to build my beans, DAOs and Gateways. (Before I go on I should mention that if you're not familiar with these terms then you should definitely check out Doug Boude's OO Terms in a ColdFusion Context. A very easy to read and comprehend document that will certainly help you to understand the basic concepts of frameworks and OO/MVC development). I've always been unsure about using code generators but for this project I'm going to look at two of them and decide which (if either) that I like. It's not that I don't think code generators are helpful but I've always been skeptical about using them. The thing thats kept me away so long has been the fact that the code that they produce rarely seems to be usable in the initial format. I believe that is intentional - no cookie cutter code ever fits everyone's needs - but I've been skeptical about the time/effort saved in customizing the code as opposed to writing from scratch. But I'm going to overlook those skepticisms and give them a shot since one of the reasons that I'm attempting to learn a framework is to write consistent, manageable code faster then I have before. The two code gen's that I'm going to evaluate are Tom Shreck's cfcPowerTools and Brian Rinaldi's Illudium PU-36 Code Generator. I may not end up using either of the resulting code in the final project, but it's worth a shot.

After I've built my Model and Controller I'll move on to actually digging into the framework and implementing my application. I believe this is a sound strategy - I typically build my CFCs first without even writing a line of code for the UI. I think it helps to build the foundation on which the UI relies before designing the interface. I know this is a highly debated topic but I'm comfortable with this way of thinking and will likely stay with it until someone convinces me not to. I believe the data should dictate the interface - not the other way around.

So that's the initial plan. Stay tuned as I do my best to document my experiences. My next few posts will focus on installing the code generators.