Rip's Domain

ICEGen not being released. Project discontinued.

Posted in ICEGen by rip747 on March 31, 2008

I’ve come to terms that ICEGen just isn’t what I want it to be after all this time. What I really want to write is something very similar to ActiveRecord or Datamapper for ColdFusion.

When CF8 was released I was really excited since it looked like my dream would finally come true with CFCOMPONENT now supporting OnMissingMethod and implicit creation for structures and arrays. OnMissingMethod works like a champ, but we all know though that implicit creation is broken and doesn’t look like it’s getting fixed anytime soon (Ben had a post saying that it would be fixed soon but we haven’t heard anything and he didn’t respond to my last post on the matter).

Because of this, I basically decided to continue development with the old code of ICEGen. After working on it for the last month I managed to get all the bugs out and it works really well. Thing is though this isn’t the project I’ve envisioned it to be, and I’m having a hard time coming to terms with that it. It’s actually kind of sad when I really sit down to look at it.

So rather then continuing to work and support a project that I can’t stand, I’ve decided to let it die. Hopefully once the implicit creation bugs get worked out, I’ll finally be able to create the ORM that I want. Sorry for anyone who wanted to see 2.0 get release, but it’s not happening.


ICEGen 2.0 preview now available

Posted in ICEGen by rip747 on February 24, 2008

ICEGen v 2.0 preview is now available for download. Below are the changes that have been made, please read them before installing. Report any bugs here. I would like to get a final version out by April 1.

DO NOT use this in production!

Remember that this is a preview, things will and could be added or removed before the final release, only use this for testing. I’m the only one who’s dieting on dog food right now.


I never really liked the XSLT way of generating code. A while back (way before I even wrote ICEGen) I downloaded ARF from Joe Rinehart and I loved the way he did the code generation. I used that method when writing this version. Because of the new way ICEGen does the code generation (thanks Joe), the speed increase has been incredible. The speed is now almost 15 fold what the last version was! To give you an idea. My database has 52 tables and it use to take around 70 seconds for it generate the files, now it takes less then 5 seconds!

ICEGen now loads from the Application.cfc

Many people didn’t like the fact that you had to run ICEGen from a browser. I did some reworking and now all you have to do is add one line to your application.cfc in the OnApplicationStart method to get ICEGen up and running. Here is the line I use

<cfset CreateObject(“component”, “icegen.icefactory”).init(“mydsn”, “mssql”, “_model”)>

Basically all you’re doing is calling the icefactory class with the following parameters:

mydsn: The name of a dsn you want ICEGen to generate classes for. You cannot pass a username and password, so you must have those settings configured within your CF Administrator.

mssql: The database type for the dsn. Right now ICEGen only supports MSSQL.

_model: This is the library path you want ICEGen to put the generated files in relative to your webroot. You MUST use dot notation for the path. ie: com.example.model

Removal of __ICEGEN__ folder and XML files

ICEGen no longer creates the __ICEGEN__ folder since it doesn’t need to create XML files any more.

Removal of __Customize__.xml file

Along with the __ICEGEN__ folder removal, the __Customize__.xml has been removed also. If you want to assign defaults to variables, you can do that from within the generated cfcs. Also a note that since this file is removed, you can’t set aliases right now. Once I figure out a good way to do this, I’ll add it back. I don’t use aliases so it doesn’t bother me, but I know some do.

Along with aliases, you will also have to call the _validateunique method yourself in your validate method to validate a unqiue value in a column. Good thing is that now you don’t have to pass the keys, so, for example, if you wanted to validate that usernames entered were unique, you would just write inside the validate method:

<cfset _validateunique(“username”, local.errors, “username_error”, “User Names must be unique”)>

username: the name of the column on the table to check for uniqueness

local.errors: this is the error collection that must be passed in

username_error: an id to add to the collection if an error is found

User Names must be unique: a message stating what the error is. Can be blank.


Here’s the problem I ran into that spawned this feature. In my test database I have a table called EventBoothNumbers that holds the booths for an event. Now these booths can have a status of either being sold, pending or reserved depending on if someone buys them, puts then into their shopping cart or if they are assigned to sponsorship package.

In order to check the status of the booth from a pure CFC way, I created a method called getstatus on the EventBoothNumbers component. Next I checked the database and depending on which table contained the boothid, I did some logic and got the status. Point being that hitting the database and performing these actions, every time I called the getstatus method was a pain in the ass and SLOW. Plus the fact that if I needed to use this logic within a query for some reason, I would have to create a view and then write another method that would just use the view instead of the base table and return the results.

First off having logic in two places is bound to cause problems at some point and needless to say it isn’t very DRY. Second off using queries defeats that point of using components. What’s the solution? Combing the view along with the base table.

When you create a view that follows the format of __{TABLE NAME}__ within your database, ICEGen will pick this up and merge any fields from that into the generated classes.

So for example. Let’s say you have a Users table with the column firstname, lastname. ICEGen would obviously create a cfc called Users with a getfirstname and getlastname method. Now if you wanted a getfullname method to combine the firstname and lastname, you would have to create that yourself.

With ICEGen all you would have to do is create a view within the database called __Users__ and in the view return the keys that match the underline table (so if the underline table has an PK called userid, the view will have to return that), plus a field called fullname that combine the firstname and lastname. ICEGen would then create the fullname method for you when the Users cfc is created.

Try it out. I know the example above is hard to follow, but trust me, you will flip when you use this feature, since it can really speed your application and development time.


All you have to do is download the file from the widget and unzip it into your webroot. Add the line to your OnApplicationStart method and you’re ready to go.

Check back here for updates.


Yes you can and always have been able to use ICEGen with multiple databases. To do this now, just add a second ICEGen load line into your OnApplicationStart method like so:

<cfset CreateObject(“component”, “icegen.icefactory”).init(“mydsn1”, “mssql”, “_model1”)>
<cfset CreateObject(“component”, “icegen.icefactory”).init(“mydsn2”, “mssql”, “_model2”)>


Here is a video showing the new feature (merging views and base tables) in ICEGen. Please be kind as this is my first screen cast.

ICEGen: Apologies, composite keys and count

Posted in ColdFusion, ICEGen by rip747 on August 6, 2007

First off, I know I have written any tutorials in the past couple of days. Life gets in the way a lot with what I want to code and write. I’m working my ass off trying to get everything out of the way so I can start writing tutorials again by this weekend.

I recently got an email asking me if ICEGen supported using composite keys. I’ve failed to mentioned in all the past posts that ICEGen has supported composite keys from day one. I originally wrote ICEGen as a code generator for myself and I’ve needed that support right off the bat.

Lastly, I actually went and updated ICEGen once again, though I’m still keeping it at RC2. This updated added support for count(). Basically I was sitting there today trying to get the number of records in the table and using the list() function to grab the records and then using RecordCount to get the number. After kicking myself in the face, I got off my lazy ass and realized that I never implemented a way to just get the number of record from a table. So count() was written today.

If you haven’t checked out ICEGen yet. I suggest you read the past tutorials and give it a whirl. It’s pretty straight forward and really easy to use. If you are using it, tell me what you like and hate about it. I’m always looking for suggestions.

ICEGen: RC2 – going Gold baby!!!!!

Posted in ColdFusion, ICEGen by rip747 on August 1, 2007

There is a problem will the zip file on RIAForge. I will reupload RC2 tonight at 6pm EST. If you want to get the RC2 code to play with, download the SVN zip by clicking here.

ICEGen has just been updated to RC2. I think I was a little premature in releasing RC1 as I had to add two more features that I thought would really make this thing shine.

First off I’ve added two more nodes to the __Customization__.xml file for columns. They are validateas and unique.

Validatead – allows you to valid a column against any validation that IsValid() does. So you can take a varchar field and have ICEGen make sure that only an email is being passed into it or a UUID and more.

Unique – Acts just like a unique constraint. You can tell ICEGen to make sure that only unique values are entered within a certain column. An example would be making sure that everyone picks a unique username.

I also added the ability to pass a structure of messages to the validate() that you would like ICEGen to use in place of just an empty string. This will should help in internationalization in your project.

I’m going to be writing tutorials everyday this week so be sure to check out the ICEGen category on this blog. I will be updating PART 4 of the tutorial to reflect the new changes tomorrow since I’m pretty burnt out (tired, not high) right now.

ICEGen: Part 4 – exploring the __Customize__.xml file

Posted in ColdFusion, ICEGen by rip747 on July 31, 2007

The heart of ICEGen is the __Customize__.xml file. This is the file that you will want to edit when you first run ICEGen. Essentially this file allows you to customize how ICEGen will generate your code. The file is located within the __ICEGEN__ directory that was created where you told ICEGen to save your generated code.

Upon opening it up will you notice that that the XML is broken down into easy to read sections like so:


Each table section or node represents a table in your DSN. Within each table node is the columns node which contains a representation of each column in that table.

In the example above I have a table named “tblContact”. To make things easier in my code I’ve decided that I wanted to rename this to “Contact” for my application. By changing the <alias> node within the table node to “Contact”, I’m telling ICEGen to now create a CFC called “Contact” that will represent the “tblContact” table. It’s important that you do not edit the <name> node as this tells ICEGen the original table name that exists inside your DSN that it will externally rename for you.

Also ICEGen allows you to do this for each column within the table also. I usually choose pretty good names for my columns, but suppose I wanted to alias the “creationdate” column by some other name, say “createddate”. All I would have to do is edit the <alias> node for the “creationdate” column and change it to “createddate”. ICEGen would then create a corresponding getter and setter for “createddate” while still internally mapping the alias to the “creationdate” column. This allows you to take badly planned or cryptic column names and turn them into names that you can understand within your model.

Besides the <alias> node, there are a couple of other nodes that you can customize with ICEGen for each column. Here’s what they do:

<required> -This allows you to take a column that normally would accept a null value within your table and make it required within your model. Say for instance that I want to make sure that each contact had a firstname. I would change the required node value to 1 and upon rerunning ICEGen, it would create the corresponding validation making this property required within my model. Valid values are 1 and 0 (default).

<default> – ICEGen tries to translate the default that you have set within your DSN for each column to ColdFusion code. As great as this may sound, there are sometimes where it just can’t do this, since each database server has it own code. This node allows you to do this yourself or change the default to something else. You’ll notice that the “creationdate” column has a default of “#now()#”, this is a default that ICEGen was able to translate from the database. But suppose I want to change this to only write the date and not the time to the column, and example would be “07/30/2007”. What I can do is edit the default for the “creationdate” column and change it to “#DateFormat(now(), ‘mm/dd/yyyy’)#”. Remember that you have to put the pound signs around any CF functions that you are going to be using.

<validateas> – Sometimes just making sure that a value is entered for a property just isn’t enough, you want to make sure that it’s a certain type. Using “validateas” can make that happen. After ICEGen checks to make sure that a value is passed in for the property it will validate as one of the following using IsValid(): creditcard, date, time, email, eurodate, ssn, social_security_number, telephone, url, uuid, usdate or zipcode. In the example abov, I’m telling ICEGen to make sure that any value entered for the email column must also be a valid email address.

<unique> –  ICEGen will make sure that only unique values are entered into this column. In the example above ICEGen will make sure that no two contacts enter in the same email address. Valid values are 1 and 0 (default).

By editing the __Customize__.xml file, you can manipulate the properties for your tables and columns for your current application within having to change the database directly. It’s important that you rerun ICEGen after making any changes to the __Customize__.xml for your changes to take affect. Also ICEGen will NOT delete any of the old CFCs that it created before. This allows you to copy already existing code from an old CFC to the new one without losing anything.

ICEGen: Part 1 – Installation
ICEGen: Part2 – Generation
ICEGen: Part 3 – Directories and Files

ICEGen: Part 3 – Directories and Files

Posted in ColdFusion, ICEGen by rip747 on July 30, 2007

During the last two installments of this (I don’t know how many) guide to ICEGen, I told you how to install and run ICEGen with your project. Now that you’ve use it to generate some code for you, I bet you’re itching to find out exactly what the hell it generated.

If you look at the directory that you told ICEGen to save it’s files to, you’ll notice two directories that were created. The first one is an “__ICEGEN__ ” directory that contains a whole bunch of xml files.The only file that you will need to worry about in this directory is the “__Customize__.xml” file. I will tell you everything you need to know how this file in the next installment of this guide. For now just put it aside in your head.

The next directory that ICEGen created was a “DAO” directory. This directory contains a whole bunch of CFCs and a directory called “generated”. You’ll notice, in the “DAO” directory, that there is a CFC for each table in your DSN, for instance if you had an “Admin” table in your DSN, you will have an “Admin.cfc” here. All the CFCs in this directory can be editted directly as they will not be overwritten the next time ICEGen runs.

If you look in the “generated” directory you will see that there are also CFCs that correspond to each table in your DSN. These CFCs are generated automatically with each time ICEGen is ran and are overwritten. The CFCs in the DAO directory above, extend these CFCs. Remeber that the CFCs in the “DAO” directory are the ones that you can edit, NOT the ones in the “generated” directory.

Take some time now and look at the files that ICEGen has genereated and check out all of the different methods available for each CFC. In the next installment we will go over the “__Customize__.xml” file and how you can use it to customize and override the output that ICEGen generates.

ICEGen: Part2 – Generation
ICEGen: Part 1 – Installation

ICEGen: Part2 – Generation

Posted in ColdFusion, ICEGen by rip747 on July 29, 2007

In Part 1 I told you how to download and install ICEGen into your project.

Now that you have ICEGen installed, it’s time to start using the thing to generate some code! Fire up your favorite browser and browse to the directory that you installed ICEGen to. If everything is kewl, your page should look like this:

icegen main page

ICEGen only has 5 settings that you need to give it to start generating code.

1) DSN Name – Enter in the name of the DSN that you have setup in your CF Administrator that you want to generate code for.

2) DSN Variable – Enter the DSN Variable that ICEGen should use to reference the DSN Name within the generated code. This is the value the will go into the dsn attribute of the cfquery tag. It can be anything you want and you must surround it with pound signs.

3) Database Type – Choose the database server type that the DSN resides on. For now ICEGen only supports Microsoft SQL Server. In the future I hope this list grows to include other database servers.

4) Save Project Path – This is where you tell ICEGen what directory you want to save the generated code to. The directory doesn’t have to be created already as ICEGenwill create the directory path if needed. Remember that this setting is relative to the webroot of the project. The path must begin with a “/”. So let’s say you wanted to save the generated code to directory; enter “/model” (without the quotes) into the field.

5) Library Path – Enter the library path, relative to the weboot, for the saved generated code. Most of the time, this will be identical to the “Save Project Path” setting. So using our directory as reference; we would enter “mymodel” (without the quotes.).

That’s pretty much it, now click “Submit” and ICEGen will start to generate the code and save it to the directory we specified. When ICEGen is finished, you will get the message below telling you that it finished and how long it took to generate the code.

ICEGen - showing the finished message

In out next installment, we’ll look at the directories that ICEGen created. Later we’ll start exploring the code.

ICEGen Part 3 – Directories and Files
ICEGen: Part 1 – Installation

ICEGen: Part 1 – Installation

Posted in ColdFusion, ICEGen by rip747 on July 28, 2007

Getting ICEGen up and running with your project is very simple. There are no mappings to configure and literally you can drop it into your project and start using it.

The first thing to do is to download ICEGen from RIAForge.

After you’ve downloaded it, you will need to unzip it.

After you unzip it, copy the unzipped icegen folder into a directory on your website. It doesn’t have to be off the root if you don’t want to.

Then all you need to do is run the thing. Suppose you saved ICEGen off the root of your website. To run it, just browse to:

ICEGen: Part 3 – Directories and Files
ICEGen: Part2 – Generation


Posted in ColdFusion, ICEGen by rip747 on July 27, 2007

Icegen finally hit RC1 last night. I’ve been using Icegen exclusively on a project that I’m doing right now for a client and it really helped to debug and get the release candidate launched.

In case you don’t know, Icegen is a code generator that uses the Active Record approach. Within no time at all you’ll have all your getters and setters, CRUD and simple validation for all your tables. This can save you mountains of time when you first start out a project.

I still want to get Oracle and MySQL Support working at some point, but the people that contacted me before about testing out the code seemed to have disappeared. If anyone would like to take on the task to help me get Oracle and MySQL support working, contact me.

ICEGen: what’s the status?

Posted in ColdFusion, ICEGen by rip747 on June 2, 2007

I’ve been trying to get the time in the last couple of weeks to work on ICEGen. Sorry to say though that work both regular and side have been very busy.  Hopefully I’ll finish what I need to do this week and be back on track by June 11th.

My first order of business is to get some documentation online via the wiki that RIAForge provides. Along with explaining what ICEGen is and how to run it, I want to give some really world example of it’s use.

After that I would like to create some screen casts that I can throw onto YouTube so I can show it in action. The only thing is that I don’t know what to use to create the screen casts, so any suggestions on software would be great. Free and open source are the best options, but I have no problems paying for something if it’s good.

After the documentation and screen casts I need to start concentrating on getting some other database support built in, especially Oracle since more than one person has emailed me about it. If anyone is willing to help me test other databases, please leave a comment below. I don’t have or know Oracle or MySQL and those are the first ones I want to concentrate on.

I’m very happy with the path it’s taken. I’m currently using it in a project I’m working on right now and I have to say that it has saved me a lot of time and thinking. The kewlest feature has to be the before and after methods for CRUD operations. It’s really nice to be able to use them like triggers and perform referential integrity with them.

If you haven’t given ICEGen a test drive, I don’t blame anyone since there is almost no documentation online, but it should be pretty easy to use. I you have used it, please leave some sort of comment below telling me what you think it needs.