Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between pages "Callisto update people" and "Graphical Modeling Framework/Tutorial/Part 2"

(Difference between pages)
(Updated with BIRT contact and improved formatting)
 
m
 
Line 1: Line 1:
== Callisto Build and Update Site Contacts ==
+
In this second part of the GMF Tutorial, some of the more advanced capabilities of the generation and runtime frameworks will be explored.  Specifically, information on adding feature initializers, diagram validation, nested child nodes, and manual extension of generated features will be covered.
  
<p>These are the (not-completely-confirmed-yet) contacts from the
+
== Feature Initializers ==
projects participating in the [[Callisto Coordinated Update Sites]].</p>
+
  
<p>Project Contacts: feel free to update this page with new or changed
+
When you create a new element on a diagram, there is typically a domain element created or modified as a result.  In some cases, it's necessary to provide additional initialization information to ensure that objects are properly created.  For example, the links we create between topics in our mindmap diagram come in three flavors: dependency, includes, and extends. The 'type' attribute of the Relationship class is used to hold the RelationshipType enum value for the new instance.  In our graphical definition, we will create a figure and corresponding link for each type, along with a creation tool for each in our tooling definition.  We'll then use a feature sequence initilizer in our mapping definition to properly initialize our domain objects, depending on the type of link created on the diagram.
information.</p>
+
  
<table border="1" align="center">
+
Another possible initialization is to set the 'label' attribute of the Relationship as well, if the appearance of the link is not enough to distinguish between the types. 
  
+
[[Image:graph_links.png|right]]
<tr valign="top">
+
<th>Project</th>
+
<th>Primary Contact</th>
+
<th>Alternate Contacts</th>
+
</tr>
+
  
 +
First, create a three distinct polyline connections with properties and decorations as you see fit. For each add a connection for each of the new Dependency, Includes, and Extends links as shown in the figure. For each connection, create a Creation Tool in your mindmap.gmftool model.
  
<tr valign="top">
+
<blockquote>
<td>Business Intelligence and Reporting Tools (BIRT)</td>
+
<font color="darkblue">'''Tip''' :</font> Don't forget that you can use copy/paste to duplicate elements in your models.  This will come in handy as you create three links, connections, tools, and mappings.
<td>Sue Lee</td>
+
</blockquote>
<td>Sissi Zhu<br />
+
Wenfeng Li</td>
+
</tr>
+
<tr valign="top">
+
<td>C/C++ IDE (CDT)</td>
+
<td>Doug Schaefer</td>
+
</tr>
+
<tr valign="top">
+
<td>Data Tools Platform (DTP)</td>
+
<td>John Graham</td>
+
</tr>
+
<tr valign="top">
+
<td>Eclipse Modeling Framework (EMF, SDO, XSD)</td>
+
<td>Nick Boldt</td>
+
</tr>
+
<tr valign="top">
+
<td>Eclipse Project (Platform, JDT, PDE)</td>
+
<td>Kim Moir</td>
+
</tr>
+
<tr valign="top">
+
<td>Graphical Editing Framework (GEF)</td>
+
<td>Steve Shaw</td>
+
</tr>
+
<tr valign="top">
+
<td>Graphical Modeling Framework (GMF)</td>
+
<td>Richard Gronback</td>
+
</tr>
+
<tr valign="top">
+
<td>Test and Performance Tools Platform (TPTP)</td>
+
<td>Hubert David</td>
+
</tr>
+
<tr valign="top">
+
<td>Visual Editor (VE, JEM)</td>
+
<td>Peter Walker</td>
+
</tr>
+
<tr valign="top">
+
<td>Web Tools Platform (WTP, WST, JST)</td>
+
<td>[[User:David williams|David Williams]]</td>
+
<td>Naci Dai<br />
+
Jeffrey Liu</td>
+
</tr>
+
  
</table>
+
<br style="clear:both;"/>
 +
 
 +
[[Image:feature_init.png|right]]
 +
 
 +
 
 +
In the mapping model, for each of your Link Mappings, create a 'Feature Seq Initializer' element.  This will hold subsequent 'Feature Value Spec' elements as seen in the figure.  OCL is the language currently supported, so be careful that the body expressions you enter are valid.  In the case of initializing the enumeration field, you'll enter 'RelationshipType::DEPENDENCY' while in the case of initilizing the label attribute, you'll enter the string value within single quotes.  Keep in mind that the order of the 'Feature Value Spec' elements will determine the order in which they are executed.
 +
 
 +
<br style="clear:both;"/>
 +
 
 +
With these steps complete, we can regenerate our mindmap.gmfgen and code. When the diagram code is generated, below is what willl be generated within the Initializers inner class of MindmapElementTypes:
 +
 
 +
<pre>
 +
public static final ObjectInitializer Relationship_3003 = new ObjectInitializer(
 +
new FeatureInitializer[] {
 +
new FeatureInitializer(
 +
"RelationshipType::DEPENDENCY", //$NON-NLS-1$
 +
MindmapPackage.eINSTANCE.getRelationship(),
 +
MindmapPackage.eINSTANCE.getRelationship_Type()),
 +
 
 +
new FeatureInitializer(
 +
"'depends'", //$NON-NLS-1$
 +
MindmapPackage.eINSTANCE.getRelationship(),
 +
MindmapPackage.eINSTANCE
 +
.getRelationship_Label())
 +
 
 +
});
 +
</pre>
 +
 
 +
During link creation, the following code is executed in CreateIncomingRelationship3XXXCommand, found in the TopicItemSemanticEditPolicy class:
 +
 
 +
<pre>
 +
protected EObject doDefaultElementCreation() {
 +
Relationship newElement = (Relationship) super
 +
.doDefaultElementCreation();
 +
if (newElement != null) {
 +
newElement.setTarget((Topic) getTarget());
 +
newElement.setSource((Topic) getSource());
 +
MindmapElementTypes.Initializers.Relationship_3004
 +
.init(newElement);
 +
}
 +
return newElement;
 +
}
 +
</pre>
 +
 
 +
This generated code within FeatureInitializer will ultimately be called on each value spec you've added, which as you can see constructs an OCL query for evaluation and uses the result to initialize the field you selected.
 +
 
 +
<pre>
 +
void init(EObject contextInstance) {
 +
if (this.query == null) {
 +
this.query = QueryFactory.eINSTANCE.createQuery(
 +
expressionBody, contextClass);
 +
}
 +
Object value = query.evaluate(contextInstance);
 +
if (sFeature.getEType() instanceof EEnum
 +
&& value instanceof EEnumLiteral) {
 +
value = ((EEnumLiteral) value).getInstance();
 +
} else if (value != null && sFeature.isMany()) {
 +
value = new BasicEList((Collection) value);
 +
}
 +
contextInstance.eSet(sFeature, value);
 +
}
 +
</pre>
 +
 
 +
<br style="clear:both;"/>
 +
 
 +
[[Image:runtime_init.png|right]]
 +
 
 +
If you launch your runtime instance and test these new initializers, you will find that the type attribute is set according to the Relationship tool selected, and that the label attribute is preset to the names you defined above.
 +
 
 +
<br style="clear:both;"/>
 +
 
 +
== Validation ==
 +
 
 +
 
 +
== Nested Child Nodes ==
 +
 
 +
 
 +
== Manual Extension ==
 +
 
 +
== Summary ==

Revision as of 09:35, 6 February 2006

In this second part of the GMF Tutorial, some of the more advanced capabilities of the generation and runtime frameworks will be explored. Specifically, information on adding feature initializers, diagram validation, nested child nodes, and manual extension of generated features will be covered.

Feature Initializers

When you create a new element on a diagram, there is typically a domain element created or modified as a result. In some cases, it's necessary to provide additional initialization information to ensure that objects are properly created. For example, the links we create between topics in our mindmap diagram come in three flavors: dependency, includes, and extends. The 'type' attribute of the Relationship class is used to hold the RelationshipType enum value for the new instance. In our graphical definition, we will create a figure and corresponding link for each type, along with a creation tool for each in our tooling definition. We'll then use a feature sequence initilizer in our mapping definition to properly initialize our domain objects, depending on the type of link created on the diagram.

Another possible initialization is to set the 'label' attribute of the Relationship as well, if the appearance of the link is not enough to distinguish between the types.

Graph links.png

First, create a three distinct polyline connections with properties and decorations as you see fit. For each add a connection for each of the new Dependency, Includes, and Extends links as shown in the figure. For each connection, create a Creation Tool in your mindmap.gmftool model.

Tip : Don't forget that you can use copy/paste to duplicate elements in your models. This will come in handy as you create three links, connections, tools, and mappings.


Feature init.png


In the mapping model, for each of your Link Mappings, create a 'Feature Seq Initializer' element. This will hold subsequent 'Feature Value Spec' elements as seen in the figure. OCL is the language currently supported, so be careful that the body expressions you enter are valid. In the case of initializing the enumeration field, you'll enter 'RelationshipType::DEPENDENCY' while in the case of initilizing the label attribute, you'll enter the string value within single quotes. Keep in mind that the order of the 'Feature Value Spec' elements will determine the order in which they are executed.


With these steps complete, we can regenerate our mindmap.gmfgen and code. When the diagram code is generated, below is what willl be generated within the Initializers inner class of MindmapElementTypes:

public static final ObjectInitializer Relationship_3003 = new ObjectInitializer(
	new FeatureInitializer[] {
			new FeatureInitializer(
					"RelationshipType::DEPENDENCY", //$NON-NLS-1$
					MindmapPackage.eINSTANCE.getRelationship(),
					MindmapPackage.eINSTANCE.getRelationship_Type()),

			new FeatureInitializer(
					"'depends'", //$NON-NLS-1$
					MindmapPackage.eINSTANCE.getRelationship(),
					MindmapPackage.eINSTANCE
							.getRelationship_Label())

	});

During link creation, the following code is executed in CreateIncomingRelationship3XXXCommand, found in the TopicItemSemanticEditPolicy class:

protected EObject doDefaultElementCreation() {
	Relationship newElement = (Relationship) super
			.doDefaultElementCreation();
	if (newElement != null) {
		newElement.setTarget((Topic) getTarget());
		newElement.setSource((Topic) getSource());
		MindmapElementTypes.Initializers.Relationship_3004
				.init(newElement);
	}
	return newElement;
}

This generated code within FeatureInitializer will ultimately be called on each value spec you've added, which as you can see constructs an OCL query for evaluation and uses the result to initialize the field you selected.

void init(EObject contextInstance) {
	if (this.query == null) {
		this.query = QueryFactory.eINSTANCE.createQuery(
				expressionBody, contextClass);
	}
	Object value = query.evaluate(contextInstance);
	if (sFeature.getEType() instanceof EEnum
			&& value instanceof EEnumLiteral) {
		value = ((EEnumLiteral) value).getInstance();
	} else if (value != null && sFeature.isMany()) {
		value = new BasicEList((Collection) value);
	}
	contextInstance.eSet(sFeature, value);
}


Runtime init.png

If you launch your runtime instance and test these new initializers, you will find that the type attribute is set according to the Relationship tool selected, and that the label attribute is preset to the names you defined above.


Validation

Nested Child Nodes

Manual Extension

Summary

Back to the top