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