Summary

• Page properties (1 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • Confluence.Code.ConfluencePageClass[0]

Details

Page properties

Content

...	...	@@ -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).

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-3604509
	1	+3604669

URL

...	...	@@ -1,1 +1,1 @@
1		-https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/WS12EclPract/pages/3604509/Textual Modeling with Xtext
	1	+https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/WS12EclPract/pages/3604669/Textual Modeling with Xtext