Java Reference
In-Depth Information
TIP
When working with custom templates, be sure to use fully qualified tem-
plate references, particularly when overriding an existing template that
might have been written using local reference paths. If you don't, you will
receive errors during execution because the template will not be resolved.
«
DEFINE
fieldPreferencePropertyChangeListener
FOR
gmfgen::GenNode-»
«
EXPAND
xpt::Common::generatedMemberComment»-»
private PreferencePropertyChangeListener preferenceListener;
«
ENDDEFINE
»
Next, we define the listener class itself, which, as you can see, needs to access
the fully qualified class name for our generated appearance preference page. This
listener class is the first to use our
toPreferenceConstant()
function for the
passed archetype.
«
DEFINE
PreferencePropertyChangeListener
FOR
gmfgen::GenNode-»
«
EXPAND
xpt::Common::generatedClassComment-»
protected class PreferencePropertyChangeListener
implements org.eclipse.jface.util.IPropertyChangeListener {
public void
propertyChange(org.eclipse.jface.util.PropertyChangeEvent event) {
if (event.getProperty().equals(
«
EXPAND
xpt::diagram::preferences::AppearancePreferencePage::qualifiedClassName
FOR
diagram».«modelFacet.metaClass.ecoreClass.toPreferenceConstant()»))
{
updateArchetypeColor();
}
}
}
«
ENDDEFINE
»
Note the navigation to the archetype's Ecore class using
modelFacet.
metaClass.ecoreClass
in the statement. The structure of the GMF generator
model is important to have handy when writing templates, and you can easily
open it from the imported project, or simply open the QVTO Metamodel
Explorer for navigator view access to the model. As you saw in the utility func-
tion, the name of the class maps to its preference constant, which is inserted in
the generated code so that the EditPart can detect changes to its color preference.
We could use a variation of this logic to avoid generating this color preference
code for non-archetype nodes.
Search WWH ::
Custom Search