I admit it; I have been behind the times for a while. Most of my ColdFusion development has been on HomeSite and I haven't been much using source control. I started using CFEclipse a few months ago, but I would still switch back to HomeSite with some frequency. I decided, however, that it is time for a change.

[More]

I just read Brian Rinaldi's article on building a code generator . He lists five steps to build a code generator. I think the article is a good one overall, but it inspired me to point out where I would (and have) done things differently.

His steps are as follows (quoted directly from is article):

1. the Admin API in ColdFusion MX 7;
2. accessing database metadata in varying RDMS;
3. converting this data to a basic XML format;
4. transforming your XML into code with XSL;
5. the CFML code necessary to bring the first four parts together into a functional application. 

1. The Admin API in ColdFusion MX 7

Brian uses this to get a list of available databases. I agree that this is nice, but I don't think it is an essential part of code generation. If someone has to type in the datasource, that doesn't completely negate the value of the code generator.

If you choose to use the Admin API, however, you might consider running your code as an extension in the ColdFusion Administrator. If you run your code in the CF Admin and you use the Application.cfm at the root of the administrator (in CFMX 7), then you will have a variable called "variables.factory". This holds the Admin API - and without you having to know the username and password. I don't think that this is a security problem as someone had to enter to the username and password to get your code to run in the first place.

I will also add in that you can see an example of how to do this as well as how to get a list of supported datasources can be found in my CodeCop code checker program.

2. Accessing database metadata in varying RDMS

I agree with Brian that this is an essential step (though Peter Bell has some good thoughts on code generation and the limits of database metadata). The approach that he used, however, means that he has to write different code for each database. He could have gotten the same information by using DataMgr. A call to DataMgr's getDBTableStruct() would get all of the same information for any database supported by DataMgr (which currently includes MS Access, MS SQL Server, MySQL, and PostGreSQL).

3. Converting this data to a basic XML format

This step isn't necessary unless you want to use XSLT for your code generation (see Peter Bell's thoughts on XSLT code generation). Assuming that you want to use XSLT, however, DataMgr can help you out again. In fact, you can skip the previous step and just have DataMgr give you an XML representation of the table structure. A simple call to getXml() will return an XML string for that table. If you need to add more information to the XML, just use ColdFusion's built in XML functions to add data to the XML.

4. Transforming your XML into code with XSL
and
5. The CFML code necessary to bring the first four parts together into a functional application

These two steps are really the same for me. This is the "generate the code" portion of the process. No doubt essential (it is the point, after all). I have already mentioned that XSLT may or may not be the best choice

Let me just mention one other tool that may be of use if you decide not to use XSLT (which is a fine option). 

I have a small component (tag.cfc ) which can be extended to be an object representation of virtually any tag. I have already extended it for cfcomponent, cffunction, and cfargument (as well as some of my own custom tags). You can use it to generate code for virtually any tag. I don't want to imply that it is better than XSLT, just another approach.

Conclusion

I really liked Brian's article. It got me thinking about how I do things differently. I have been intending to work on my code generator again for some time (I actually use it for myself on most new projects, but it isn't quite "ready for Prime Time" yet). Hopefully I can work on that again as soon as I release DataMgr 2.0. 

UPDATE

Here is a handy link to Brian's response (so you don't have to copy and paste from the comment below):

http://www.remotesynthesis.com/blog/index.cfm/2007/1/17/Generating-Code-vs-Generating-Applications  

While busy with several urgent projects, I spent most of yesterday improving my tool set. This might seem like a bad time, but I think it will pay of well.

I found that I was performing several tasks several times. My general rule is that on the third time I perform the same task, I try to automate it. I found that I had several tasks that I had performed more than three times and that I would need to perform more times very soon for my urgent problems.

Abraham Lincoln said "Give me eight hours to chop down a tree and I will spend the first six sharpening the axe." I think this is a valuable (which has been discussed as Sharpening the Saw). 

I think that time spent improving your tool set is time well spent. Be careful, however, not to try to wait until your tool set it perfect before you start your work.

I find it is valuable to improve my processes and tool set a little bit every project. I find that in the long run, the time a save as a result more than makes up for the investment of time in improving your tools. 

In this case, DataMgr received some major improvements. I was planning to make these upgrades a 1.5 release, but they have already had such a major impact on my coding, that I might rename the release 2.0 (still plenty of testing before it is ready though).

According to his quote, Abraham Lincoln would spend two thirds of his time improving his tools. I suspect he was exagerating a bit. I spend about a sixth of my time improving my tools.

If you are using any of the three major ColdFusion frameworks (Model-Glue, Mach-II, Fusebox), Massimo Foti has put together a Dreamweaver extension to make your life easier.

As I am not currently using any of the major frameworks (I am a recovering Fuebox addict), I haven't tried the extensions. Massimo has been responsible for plenty of other good work, however, so I am confident that these won't dissapoint.

You can find them on the Dreamweaver Extensions portion of his site, or use the following URLs for direct access to the extension of your choice.

http://www.massimocorner.com/dreamweaver/coldfusion/model-glue.mxp
http://www.massimocorner.com/dreamweaver/coldfusion/mach_ii.mxp
http://www.massimocorner.com/dreamweaver/coldfusion/fusebox.mxp

As I said, Massimo has done plenty of good work. If you go to his site, I recommend that you take the time to peruse his other free ColdFusion offerings as well (be sure to read the license first though).

Recently, a few ColdFusion programmers have written code generators. I was pretty excited about this until I realized that they don't write code the way I write code. I figured I wasn't the only one to want code generation "my way".

So, I started work on a code creator that would write code however you want it. The code creator provides a wizard and tools for creating a code generator. The generator is a cfc that extends a provided Generator.cfc. Each generator would take the information from the wizard and creates code from it.

Keep in mind that this is just a preview at this point. That being said, feel free to take a look and give me any feedback.

http://www.bryantwebconsulting.com/clients/generator/

I know it still needs plenty of work, but I am curious if this is something that others would find useful and what improvements other see that it needs.

Things I know that I need to add:

• The ability to select the type of form field based on the datatype.
• Limit the length of the form fields based on the length allowed in a column.