The art of code generation: More like sculpting than painting

Programming and art have a lot of similarities. I’d like to think it’s sometimes a lot closer to sculpting out of clay than, say, painting on a canvas. Especially when developing code generators.

I’m now hard at work developing a generated CMS tool that complements the generated Actionscript and data-modeling framework based off of our methodologies.

Content management systems are interesting because, moreso than any other kind of application, they speak to the idea that data models and interfaces very much mirror each other in the real world. Updating content through a CMS is really about updating a database in a much more fluid way than going into the db directly.

When you build a framework for general application development, you can only go so far. In fact, our generated Actionscript layer really only creates a value objects layer and base classes for views– nothing further. There’s too many potential variables on the interface level to really generate anything specifically with success.

But a CMS has a very specific purpose with very specific goals. You can get much closer to the end goal of generating an entire CMS without doing any additional coding than you could with a generic application.

The code generator I’m working on will essentially generate an excessive amount of stuff. Generally speaking, for each object in the data model,

  • A listing page (e.g. A collection view of an object) with customizable labels and displays (e.g. Show me a list of user’s first and last names, labeling them as “Full Name)
  • An add page (e.g. An item view of an object) customizing the order of the object’s attributes and related collections/items
  • An edit page similar to the add page
  • Searching and paging for each object
  • Links to related entities off each object’s listing page (e.g. A link to a user’s related purchases for an e-commerce management CMS)
  • CMS metadata wrapped around each object (e.g. Instructions on the listing page of each object)
  • Etc. etc.

As I continually add on functionality to the generated CMS, I’ll inevitably do more than is necessary. Not every page in the CMS needs the same level of robustness, even though the generator will treat each object in the same way.

In this case, it’s much easier for me (the CMS developer) to have a generator create too much stuff and let me decide what things aren’t necessary. To that end, generating the CMS is like creating a big clay block. Let’s create everything we need, then chisel off the bits we don’t after it’s already been created.

My goal for this generator is to overshoot the end goal of a production-ready CMS and streamline it afterward. It will ultimately be a much faster way of development than trying to tack on too many initial parameters (e.g. For this object, don’t generate the search page, and for that object, don’t have instructional text on the listing page). And, when the client comes back wanting some additional features I hacked off, I can just ask the generator to redo it for me.