| ... |
... |
@@ -10,7 +10,7 @@ |
| 10 |
10 |
|
| 11 |
11 |
An Xtext grammar is always related to a specific EMF meta model. The grammar defines a concrete syntax in which instances of the meta model (the abstract syntax) can be serialized and stored. Xtext supports two ways of linking a grammar with a meta model: either creating a grammar for an existing meta model, or creating a grammar first and generating a meta model out of it. Here we will use the former approach, reusing the meta model for Turing Machines that you already defined earlier. |
| 12 |
12 |
|
| 13 |
|
-1. Install the //Xtext Antlr Runtime Feature// from [[http:~~/~~/download.itemis.de/updates/>>url:http://download.itemis.de/updates/||shape="rect"]] |
|
13 |
+1. Install the //Xtext Antlr Runtime Feature// from [[http:~~/~~/download.itemis.de/updates/>>url:http://download.itemis.de/updates/||shape="rect"]] (click //Help// → //Install New Software...// and enter the URL into the topmost text field; once Eclipse has downloaded the list of software available under that URL, select the feature from the list) |
| 14 |
14 |
1. //File// → //New// → //Project...// → //Xtext// → //Xtext Project From Existing Meta Models// → //Next// → //Add...// → turing.genmodel → //OK// |
| 15 |
15 |
1. Select your top-level model element as "//Entry rule//", e.g. //TuringMachine// → //Next// → enter the following values:\\ |
| 16 |
16 |
1*. //Project name~:// de.cau.cs.rtprak.login.turing.text (like in previous tutorials, replace "login" by your login name) |
| ... |
... |
@@ -55,11 +55,11 @@ |
| 55 |
55 |
|
| 56 |
56 |
= Formatting = |
| 57 |
57 |
|
| 58 |
|
-Xtext supports automatic formatting, which is available in the text editor with right-click → //Format// or ctrl+shift+F. However, the formatter must be configured in order to generate good results. Write a formatter configuration that fits well to your syntax by editing the generated file {{code language="none"}}TuringFormatter{{/code}} in the {{code language="none"}}formatting{{/code}} subpackage. Learn how this is done by reading the Xtext reference documentation → Runtime Concepts → Formatting. |
|
58 |
+Xtext supports automatic formatting, which is available in the text editor with right-click → //Format// or ctrl+shift+F. However, the formatter must be configured in order to generate good results. Write a formatter configuration that fits well to your syntax by editing the generated file {{code language="none"}}TuringFormatter{{/code}} in the {{code language="none"}}formatting{{/code}} subpackage. Learn how this is done by reading the [[Xtext reference documentation>>url:http://www.eclipse.org/Xtext/documentation.html||shape="rect"]] → //Runtime Concepts// → //Formatting//. |
| 59 |
59 |
|
| 60 |
60 |
= Validation = |
| 61 |
61 |
|
| 62 |
|
-The generated code includes some automatic validation of models with respect to syntactic issues. If the token sequence in a text file does not conform to the grammar, error markers are shown at appropriate points in the text. However, this should be augmented by semantic validation by checking high-level properties of the model. Implement such a semantic validation by editing the generated file {{code language="none"}}TuringJavaValidator{{/code}} in the {{code language="none"}}validation{{/code}} subpackage. Learn how this is done by reading the Xtext reference documentation → Runtime Concepts → Validation → Custom Validation. You should implement at least the following checks: |
|
62 |
+The generated code includes some automatic validation of models with respect to syntactic issues. If the token sequence in a text file does not conform to the grammar, error markers are shown at appropriate points in the text. However, this should be augmented by semantic validation by checking high-level properties of the model. Implement such a semantic validation by editing the generated file {{code language="none"}}TuringJavaValidator{{/code}} in the {{code language="none"}}validation{{/code}} subpackage. Learn how this is done by reading the [[Xtext reference documentation>>url:http://www.eclipse.org/Xtext/documentation.html||shape="rect"]] → //Runtime Concepts// → //Validation// → //Custom Validation//. You should implement at least the following checks: |
| 63 |
63 |
|
| 64 |
64 |
* Is there exactly one initial state? |
| 65 |
65 |
* Are all states reachable through transitions starting from the initial state? |
| ... |
... |
@@ -66,7 +66,7 @@ |
| 66 |
66 |
|
| 67 |
67 |
= Parsing = |
| 68 |
68 |
|
| 69 |
|
-The generated code includes a parser for text files in your syntax. This parser is simply used with the same interface as for any other EMF models: resource sets. Your final task for this tutorial is to reuse the Turing controller you implemented in the EMF tutorial for simulating Turing Machine models, this time applying it to {{code language="none"}}.tuxt{{/code}} text files. However, instead of using a fixed path to your model file, we will now use a //menu contribution// in order to set the file path dynamically. This contribution will be put into the popup menu of the //Navigator// / //Project Explorer// view by configuring a visibility expression that tests the currently selected (right-clicked) elements. The contribution shall only be visible if the selected files have the extension tuxt, which is assigned to our mighty textual syntax. |
|
69 |
+The generated code includes a parser for text files in your syntax. This parser is simply used with the same interface as for any other EMF models: resource sets (see the [[Xtext reference documentation>>url:http://www.eclipse.org/Xtext/documentation.html||shape="rect"]] → //Integration with EMF and Other EMF Editors//). Your final task for this tutorial is to reuse the Turing controller you implemented in the EMF tutorial for simulating Turing Machine models, this time applying it to {{code language="none"}}.tuxt{{/code}} text files. However, instead of using a fixed path to your model file, we will now use a //menu contribution// in order to set the file path dynamically. This contribution will be put into the popup menu of the //Navigator// / //Project Explorer// view by configuring a visibility expression that tests the currently selected (right-clicked) elements. The contribution shall only be visible if the selected files have the extension tuxt, which is assigned to our mighty textual syntax. |
| 70 |
70 |
|
| 71 |
71 |
1. Go to the plugin where you created and registered {{code language="none"}}TuringHeadController{{/code}}, the Turing Machine simulator. Open {{code language="none"}}plugin.xml{{/code}} → //Dependencies// and add org.eclipse.ui if not on the list yet. Go to //Extensions// and add org.eclipse.ui.menus. |
| 72 |
72 |
1. Add a //menuContribution// element to the new extension and set "popup:org.eclipse.ui.popup.any?after=additions" as //locationURI// (without quotation marks). |
| ... |
... |
@@ -82,8 +82,8 @@ |
| 82 |
82 |
1*. //property~:// org.eclipse.core.resources.extension |
| 83 |
83 |
1*. //value~:// tuxt |
| 84 |
84 |
1. Add a new extension org.eclipse.ui.commands and add a //command// element to it with the following attributes:\\ |
| 85 |
|
-1*. //id~://de.cau.cs.rtprak.login.setSimFile |
| 86 |
|
-1*. //name~://Set Simulation File |
|
85 |
+1*. //id: //de.cau.cs.rtprak.login.setSimFile |
|
86 |
+1*. //name: //Set Simulation File |
| 87 |
87 |
1*. Click on //defaultHandler// to open a dialog for creation of a new handler class. Name the new class {{code language="none"}}SetFileHandler{{/code}} and put it into some package of that plugin. Remove the suggested interface and set {{code language="none"}}org.eclipse.core.commands.AbstractHandler{{/code}} as superclass instead. |
| 88 |
88 |
1. ((( |
| 89 |
89 |
Use the following method stub for SetFileHandler{{code language="none"}}{{/code}} (this requires a plugin dependency to org.eclipse.core.resources): |