Getting started with mogenerator

Or mind the (generation) gap…

If you’ve done any development in WebObjects, you’ll know that EOModeler generates a class file for each entity you define in the model. Which is very nice of it, and a very tempting place to put your own custom business logic. Too tempting, in fact, because now when you go back to the model and make changes, EOModeler can’t simply overwrite the file since it has your code in it too. (Actually, it can overwrite the file if you click the wrong button, but that’s not EOModeler’s fault). Instead you have to merge EOModeler’s changes in with your own code, which can be time consuming and a possible source of errors.

Enter the generation-gap design pattern: instead of one file, have two. One that EOModeler maintains, and one that is a subclass of EOModeler's file, into which you can put your own code. Change the entity in the model, and only the first file needs to be updated.

This can be done manually, but it is a chore to do. The wonderful EOGenerator is a command-line tool which generates the required files, and provides lots of other goodies too.

But what about Core Data? The same problem exists: mixing auto-generated and hand-written code in the same file, compounded by the fact that there are twice as many files (.h, .m) compared to WebObjects (.java). Fortunately there is a similar solution, with a similar name: mogenerator.

The site does have the following caveat:

Right now things are working, but raw. I need to get my Xcode integration story tight, write some docs, an install script and then do a real binary release (instead of just pointing to a SourceForge subversion folder). But that won’t happen for a little while, so here’s my “release early, release often” shot. More postings as it matures.

What? No documentation? No install script? No binary release? No nice Universal application with shiny icon and a one-click “Create files” approach? What has the author of mogenerator been doing with all their time? It is not as if he’s been organizing a conference or something…

Anyway… To get started with mogenerator:

1Grab the source for mogenerator and MiscMerge from the repository at http://svn.sourceforge.net/viewvc/redshed/trunk/cocoa/

2Put both mogenerator and MiscMerge in the same directory to keep the path relationships happy

3Make a folder called mogenerator in ~/Library/Application Support/ and move the four *.motemplate files into there.

4Open mogenerator.xcodeproj

5Click ‘Build’.

The mogenerator executable will be built in build/Release/, or wherever you have Xcode set up to build.

Check it is working at least by cd’ing to that directory and:

david$ ./mogenerator -version
mogenerator 1.0.1. By Jonathan 'Wolf' Rentzsch.

Clues as to how to use it can be found by doing:

david$ ./mogenerator -help
mogenerator [-model /path/to/file.xcdatamodel] [-baseClass MyBaseClassMO] [-includem include.m] [-version] [-help]
Implements generation gap codegen pattern for Core Data. Inspired by eogenerator.
		

Wondering why we copied the four *.motemplate files into ~/Library/Application Support/mogenerator earlier? Without that step you’d get errors of the type MiscMergeTemplate: Could not read template file /Users/david/Library/Application Support/mogenerator/machine.h.motemplate and so on: one for each of the four template files. But since these files are in place we can go ahead and generate the files for our project:

david$ ./mogenerator -model ~/Projects/Test/Test.xcdatamodel
		

The resulting files will be placed in the same directory as the mogenerator executable, so if you’re using this in a real project you’d probably want to move things around so that the files are generated in the appropriate place. Four files will be generated for each class in the .xcdatamodel. The two files with a leading underscore are the machine-generated files which shouldn’t be edited by hand. Anytime the .xcdatamodel changes, re-run mogenerator, and it’ll update the machine-generated files, leaving your custom logic in the other two files alone.

Four files are also generated for NSManagedObject, which is what entities without a custom class will default to. I’m not sure why I’d want these four files since the default behavior would be desirable — after all, if I wanted to add custom logic to them, I’d have made them a custom class.

I look forward to seeing how mogenerator matures — right now it is already the quickest and easiest way of generating generation-gap files for custom classes in Core Data.

[Update] With the release of v1.1 of mogenerator, I've written a revised post about getting started with mogenerator v1.1.