Java Reference
In-Depth Information
Finally, this the workflow file used to invoke the templates using a test
dynamic instance model. This is the same model that was used to feed the
dnc2jee.qvto transformation.
<?xml version="1.0"?>
< workflow >
< property name="model" value="org.eclipse.dsl.dnc/model/model.xmi" />
< property name="out" value="../org.eclipse.example/src-gen2" />
<!-- set up EMF for standalone execution -->
< bean class="org.eclipse.emf.mwe.utils.StandaloneSetup">
< platformUri value="../" />
</ bean >
<!-- load model and store it in slot 'model' -->
< component class="org.eclipse.emf.mwe.utils.Reader">
< uri value="platform:/resource/${model}" />
< modelSlot value="model" />
</ component >
<!-- generate code -->
< component class="org.eclipse.xpand2.Generator">
< metaModel id="mm"
class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel" />
< expand value="templates::java::dnc2java::Main FOR model" />
< outlet path="${out}">
< postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/>
</ outlet >
</ component >
</ workflow >
BEST PRACTICE
Note the use of the JavaBeautifier in the generator component's outlet ele-
ment. Generally, it's better to rely on code formatters for generated code
than sacrifice readability of the template itself in an effort to generate
nicely formatted output directly. However, it's often necessary to strike a
balance because the Toolsmith must also be able to understand the code
generated by the template.
Looking back at our two approaches, it's hard to say that one is better than
the other. The template-only approach seems a bit simpler, but this ultimately
depends on your personal preference and familiarity in working with QVTO and
Xpand/Xtend. I did notice that many similar yet different constructs exist in
OCL/QVTO and Xpand/Xtend. This makes the GMF Xpand engine's use of
 
Search WWH ::




Custom Search