User Manual

Inheritance

When one model (the inheritor) inherits from another (the ancestor), it gains all of the properties of the ancestor, in addition to any the inheritor may define itself. In a way, the inheritor IS an instance of the ancestor, in that it has all of the qualities of the ancestor and can be treated interchangeably with it, but it defines its own properties as well, elaborating on the design of the ancestor with some additional structure.

To inherit one model from another, go to the inheritor model’s configuration screen (the gear in the model bar at the bottom left). There is a menu of models that can be inherited from. Choose one and hit Save. There is nothing preventing multiple models from inheriting from the same model, or from a model to inherit from a model that itself inherits from a third model.

One way inheritance can be used is in modeling relationships between people. People share many qualities: names, email addresses, height, age etc. Sometimes there are many different roles a person could play in the system. A bulk could be users, but others could be administrators, and another group could be designers, or developers. All of them share basic person information, but each also has different relationships to other models in the system. One solution could be to define a Person model with all of the basic information, then define the other more specific groups as inheritors of Person. So Developer could inherit from Person, and also have relationships to various projects they have worked on, or technologies they have used, which would not be contained in the Person model itself.

This would have the added advantage that all People in the system could be treated uniformly if necessary. You could use the content tag to retrieve a group of content from the ‘Person’ model, irrespective of whether they were a Developer or Administrator, or just a vanilla Person. Then, if you wanted just Developers, you could query that model later. The ability to treat the same content from multiple perspectives can improve many designs.

Another way to use inheritance could be for commentable forum-style site. Perhaps in this site, anything could be commented on. Images, Posts, Ads, Tags, Users, even other Comments. You could make the Comment model have a “belongs to” relationship to all of these other models, but then from the Comment model’s perspective, you would have to go through every possible association to see what it actually belonged to. Thinking about it from the perspective of a Comment, really a Comment belongs to some Commentable thing. It doesn’t care whether it is an Image, a Post or whatnot. It is just whatever it is a comment on.

So, one solution would be to create a Commentable model that has a “has many” association to Comments, and any other properties common to all of these components of the site (perhaps votes, or favorites?). Then, each of the commentable things could inherit from Commentable. They would all inherit this association to Comment, and all of the Comments would only ever belong to one thing at a time, just as it should.

This ability to create a “root” model that allows you to treat all of the inheritors the same way is a powerful technique that has the ability to prevent a lot of redundancy in the system.