There are two kinds of inheritance that are useful for applications in the Fabulator universe: is-a and has-a. There are also other kinds of inheritance in object oriented programming (OOP): mixins, interfaces, and other ways of tweaking an object class. We aren’t using those in our Fabulator applications though.

The ‘is-a’ inheritance is handled by using a clone of the inherited application to compile the XML description of the inheriting application. Thus, ‘is-a’ inheritance is managed by the framework embedding the Fabulator engine and not by the engine itself. Since the storage of application definitions is defined by the embedding framework, the engine does not try to find the parent application from which it needs to inherit.

The current way to declare inheritance is through the ‘@is-a’ attribute on the ‘application’ root element. With the Fabulator embedded in Radiant, this should point to the path of the page in Radiant that holds the parent application.

The current code (not yet pushed to Github) manages actions and the ability to call the actions in the parent application at will using the new ‘super’ element. This element takes a ‘select’ attribute that provides the initial context for the parent actions. The parent application’s actions are only accessible using an action element. They are not accessible within an expression. This is because of when the needed information about the parent actions is available. If the engine were implemented slightly differently (and this might be the case eventually), then it might be possible to allow access to the parent application’s actions from within expressions.

This kind of inheritance is required before we can create a simple skeleton application for some common digital humanities task and then customize it for a particular project.

Has-a inheritance is a bit trickier and will have to wait until a bit later.