Using moGenerator as part of the Build Process (XCode)

Using Core Data is awesome.

moGenerator makes it even better, as you can have Entitites defined as being of a particular class, and this code generator creates two classes for each Entity - a machine-readable one which is updatable by running the script again, and a human readable one that you can safely edit - it won’t be changed once it has been created.

You can easily make this tool a part of you build process.

First, create a new directory inside your project folder, I called mine MO. Then, cd to that directory, and run:

$ mogenerator -m ../*_DataModel.xcdatamodel

Then add the folder MO to your project.

Now add a new build phase script, and put into it:

cd MO
mogenerator -m ../*_DataModel.xcdatamodel

It’s not quite perfect - if you add a class, it won’t be added to your project automatically. You might be able to get around this by including the -includem switch, but then you won’t be able to have the .m files located in your project, else you will get duplicate symbol errors.

Mercurial and Trac

I’m enamoured with Mercurial for all of my version control needs. I’d like Versions to work with it, but the response I got from the developer suggests it never will. “UI of Versions is designed completely around the concept of centralized version control “ I can see that the same type of interface would work quite well with Mercurial, or another DVCS, without too many hassles.

Still, even just with the CLI, I’m coping.

A couple of days ago I started playing with Trac for bug tracking. I had used Bugzilla (not for my own projects, but I use it at work), and it doesn’t work properly with Mercurial. The good news is that Trac does, almost out of the box.

The trac-post-commit-hook works fine, and allows me to have a repository linked in with my trac store, and when changes are checked in that have “fixes ticket:X”, it automatically updates the trac for that ticket. It’s a bit of a repetitive process to set it up (you have to manually edit both the repo/.hg/hgrc file, and the trac/trac.ini file to add support for each other, but it’s easy enough to do).

The only annoyance is that the username isn’t quite the same in both - so changes made in Trac have the username matt, whilst those made in mercurial have the default username there - which includes my full name and my email address.

To-Many Relations in Core Data using Cocoa Bindings

I’m currently learning stacks (and maybe developing a useful application along the way) about Core Data and Cocoa Bindings.

I managed to hook up all of the “first level” Entities to UI elements, but was struggling a bit figurng out how to get the to-many relationships to work.

To make all elements of the type Person appear in an NSTableView, you can create an NSArrayController, set it to the Entity type, and put Person in the relevant field. Then all people will appear in the list.

If you have a manager, who might supervise zero or more people, then how do you get a sub-set of People. More specifically, how do you get a just the other side of a To-many relationship.

I thought I was going to have to resort to actually writing some code, and use a Predicate, or something like that. But there is an IB only method.

You can create an NSArrayController, and as well as putting in the Entity type (and hooking it up to the Managed Object Context), just put that it gets it’s Content Set from another object - in this case it would be People.selection.supervises (or whatever it is called).

This isn’t quite flawless - if you just hook up a button to the “add:” outlet, then it doesn’t quite add properly - the reverse of the attribute is not set. I had to make up an IBOutlet in my window controller that creates a new component, and sets the relationship up.

Which meant I ended up having to write two lines of code. For each relationship.