Java Reference
In-Depth Information
getPreferenceColor()
. All that's left to do is test the functionality and then
move on to templatizing the code changes. One improvement might be to restrict
the color ranges for each archetype so that they still maintain their pink, yellow,
green, or blue essence.
We begin our GMF diagram template spelunking in the
/templates
direc-
tory of the imported
org.eclipse.gmf.codegen
plug-in. We notice right away
that there are three editparts directories: one under
/templates/diagram
, one
under
/templates/impl/diagram
, and one under
/templates/xpt/dia-
gram
. The last one is a legacy structure and should be ignored in favor of the
/templates/impl
pattern to distinguish published API vs. non-API templates.
Looking into each and finding a
NodeEditPart.xpt
template in the first two,
we open each to see the differences. In the
/templates/diagram/
editparts/NodeEditPart.xpt
template, we see that it delegates to the
/templates/impl/diagram/editparts/NodeEditPart.xpt
template for
generation of the class content. What interests us most, however, is the
«EXPAND
additions-»
expansion near the end of the class. All we need to do is add the
code listed earlier to our archetype
EditPart
classes, so this looks like a prom-
ising place to start. In fact, this expansion was designed for Toolsmiths to use for
customizing the generated code, and you'll find many of them in the GMF tem-
plates. The corresponding
«DEFINE»
block appears at the bottom of the
template and is listed here:
«
DEFINE
additions
FOR
gmfgen::GenNode-»
«
ENDDEFINE
»
TIP
If you need additional extensibility in GMF templates, open a bug to request
the change be made.
We need to create a
NodeEditPart.xpt
template file in our
org.
eclipse.dsl.dnc
project in a
/templates/aspects/diagram/editparts
folder. Again, we conform to the GMF convention of aspect template placement
so that the generator will invoke our template. We place an
«AROUND»
block at
the top of the template, as follows:
Search WWH ::
Custom Search