Tag Archives: MWE

Xpand templates on XSDs

The screen definitions of our application are part of our model as well. They need to be exported to XML to be processed by our screen-interpreter at runtime. Our client is based on Eclipse RCP and we allow to apply hooks to certain steps within the interpretation process. This is required to let the developer implement behavior that differs from the standard behavior of the interpreter. Hooks are registered via an extensions using the name of a model element for identification.

The code within a hook references UI elements as it implements UI behavior. To access an element, it’s name has to be used as well, and that is quite error-prone. The name within the model might change but the code still references the old. So we decided to use Xpand to generate descriptors (it is only a list of String constants to be honest) for the modeled UI elements. The developer may use the constant, so the code will fail to compile if the name of the element changes in the model.

Generating these constants is a pretty easy thing as the XSD for the screen model can simply be used as meta-model.

...
<component class="org.eclipse.xtend.typesystem.xsd.XMLReader">
   <modelSlot value="model" />
   <uri value="${screen.model.project}/model/screen.xml" />
   <metaModel id="screenXMLModel">
      <schemaFile value="${screen.profile.project}/model/screen.xsd" />
      <registerPackagesGlobally value="true" />
   </metaModel>
</component>
...

When activating the XSD metamodel within the project preferences in the Eclipse IDE, the Xpand editor recognizes an XSD in the project’s classpath as metamodel and you may start creating the templates.
Pretty easy and very handy!

Tuning Xpand Templates

Our current project is model driven, using MWE, Xpand & Xtend. Right at the beginning, our templates were really fast and the round trip time was fairly acceptable. By now, our model contains quite a lot of elements and a generator run takes far more time than before. So I had a look what can be done to tune our templates a little.
When studying the Xpand docs, I found something interesting: The cached keyword for Xtend functions. A return value of cached functions is stored for the given parameter(s) and this turns out to be very useful. We have a lot of typeSelect() operations to do something on specific model types, for example on all our Services, in both Xpand templates and Xtend functions.
... eRootContainer.eAllContents.typeSelect(Service) ...
This statement results in scanning the whole model for elements of the desired type. Usually you expect the result to be the same each time (at least you should hope). This piece of code is a perfect example for a cached Xtend function that replaces all occurrences of the upper statement.

cached List[Service] services(EObject eRootContainer):
eRootContainer.eAllContents.typeSelect(Service);

So the model is scanned only once, as the eRootContainer is always the same object. This saves a lot of time. If you provide such a function for each type you need, your templates will be processed much faster. I know, caching is a little dangerous, but well dosed it can be quite useful and reduces the required time for a round trip.

From OAW to MWE…

I’m currently migrating a model driven project from OAW to MWE. While changing all package declarations in the workflow and finding the right MWE counterpart elements is not too complicated, keeping the whole automated building thing working is not as easy as I thought though. The model export from UML to XMI is still bound to the OAW packages, so the export and generate steps need to be separated and executed back-to-back… pretty tricky but necessary… If you face the task of migrating an oaw project, maybe these blog entries from Karsten Thoms or Ekkehard Gentz help you a little.