-
Notifications
You must be signed in to change notification settings - Fork 0
Workbench models and the eclipse modelling framework
The Eclipse Modeling Framework (EMF) is a way of describing domain objects in models, then generating code from the model. The objects, relationships and properties of any model will vary wildly, but all domain code can use some of the same API elements. So it is efficient to generating code a relatively large amount of code from a small model.
The EMF supports the creation of models from scratch. This is how the Crosswalk model was created. It can also support extraction of a model from a XSD schema, which was how I created a model for METS and MODS. The advantage of extracting a model from the XSD is that we then get the ability to load instances of the model from valid XML and persist instances of the model to valid XML.
The METS Project Nature loads and saves a METS model instance that is kept in an XML file within the project. Whenever a project is open, the METS Project Nature has our loaded METS model. This METS document is where most of the Workbench metadata is kept and where most of the files are tracked. (An exception is that Original files are not tracked in METS until they are captured/selected.)
The MODS model was likewise extracted from the MODS schema. Domain code was then generated from the model. Taking it a step further, an editor was also generated from the model. This editor provides a user interface for modifying MODS models, which can then be persisted back into XML.
The Eclipse Modeling Framework is called a "code merging" framework. This is because a model defines an interface without completely defining how operations are implemented. There are parts of the domain that need to be coded by hand or modified. Editors are also customizable, which is a good thing since the auto-generated editors are not always easy to use. With XML schemas especially, the full complexity of the schema is the enemy of a user friendly interface. Some steps have been taken to hide the full complexity of the MODS schema, while still supporting it completely.
In the case of METS, the Workbench itself is an attempt to hide the underlying METS domain. It lets the user create valid METS without looking at the XML elements at all.
We define a crosswalk by creating an instance of the Crosswalk model and saving it to XML. The Crosswalk Model started out as a model created in EMF ECore format. All it parts and their interconnections were laid out in advance in a model editing tool. This model was saved and then code was generated from there.
There is a parallel framework to EMF, called the Graphical Modeling Framework, which was used define the visual aspects of the Crosswalk editor. The visual model and the domain model were merged and then editor code was generated from both of these. Below is the complete list of modelling files that define the crosswalk editor:
- /crosswalk-gmf/model/crosswalk.ecore
- /crosswalk-gmf/model/crosswalk.genmodel
- /crosswalk-gmf/model/crosswalk.gmfgen
- /crosswalk-gmf/model/crosswalk.gmfgraph
- /crosswalk-gmf/model/crosswalk.gmfmap
- /crosswalk-gmf/model/crosswalk.gmftool