Skip to Content
Last modified by Richard Kreissig on 2025/01/30 12:03
From version 13.1
edited by msp
on 2012/11/01 13:57
Change comment: There is no comment for this version
To version 5.1
edited by msp
on 2012/10/31 19:58
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -48,66 +48,5 @@
48 48  
49 49  * The predefined grammar contains one grammar rule for each meta model class. This general structure can be kept in most cases.
50 50  * Ecore enumerations (EEnum) must be defined with an {{code language="none"}}enum{{/code}} grammar rule (see documentation). This is not correct in the predefined grammar and is marked with a TODO note.
51 -* At some points you will need to reference other elements, which need to have some kind of identifier string in order to do this. If those elements do not have a string attribute yet, you need to modify the meta model and add such an attribute.
52 -* There are some predefined terminal rules that can be reused and are already imported in the grammar file. Click on {{code language="none"}}org.eclipse.xtext.common.Terminals{{/code}} at the top of the document and hit F3 to see those terminal definitions.
53 53  
54 -Test the new grammar by re-generating the code (after the first time, the GenerateTuring workflow should be available in the run configurations menu) and starting a test instance of Eclipse. Use your newly designed textual syntax for writing a Turing Machine that copies the input word infinitely often.
55 -
56 -= Formatting =
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>>url:http://www.eclipse.org/Xtext/documentation.html||shape="rect"]] → //Runtime Concepts// → //Formatting//.
59 -
60 -= Validation =
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>>url:http://www.eclipse.org/Xtext/documentation.html||shape="rect"]] → //Runtime Concepts// → //Validation// → //Custom Validation//. You should implement at least the following checks:
63 -
64 -* Is there exactly one initial state?
65 -* Are all states reachable through transitions starting from the initial state?
66 -
67 -= Parsing =
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 (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 -
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 -1. Add a //menuContribution// element to the new extension and set "popup:org.eclipse.ui.popup.any?after=additions" as //locationURI// (without quotation marks).
73 -1. Add a //command// element to the //menuContribution// with the following attributes:\\
74 -1*. //commandId: //de.cau.cs.rtprak.login.setSimFile
75 -1*. //label: //Set Simulation File
76 -1. Add a //visibleWhen// element to the //command//, and add an //iterate// element to the //visibleWhen// with the following attributes:\\
77 -1*. //operator~:// and
78 -1*. //ifEmpty~:// false
79 -1. Add an //adapt// element to the //iterate// with the following attribute:\\
80 -1*. //type~:// org.eclipse.core.resources.IResource
81 -1. Add a //test// element to the //adapt// with the following attributes:\\
82 -1*. //property~:// org.eclipse.core.resources.extension
83 -1*. //value~:// tuxt
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
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 -1. (((
89 -Use the following method stub for SetFileHandler{{code language="none"}}{{/code}} (this requires a plugin dependency to org.eclipse.core.resources):
90 -
91 -{{code theme="Eclipse" language="java"}}
92 -/**
93 - * {@inheritDoc}
94 - */
95 -@Override
96 -public Object execute(ExecutionEvent event) throws ExecutionException {
97 - ISelection selection = HandlerUtil.getCurrentSelection(event);
98 - if (selection instanceof IStructuredSelection) {
99 - Object element = ((IStructuredSelection) selection).getFirstElement();
100 - if (element instanceof IFile) {
101 - IFile file = (IFile) element;
102 - // TODO update the static reference to the simulation file
103 - }
104 - }
105 - return null;
106 -}
107 -{{/code}}
108 -)))
109 -1. Add a public static field named {{code language="none"}}modelFile{{/code}} to {{code language="none"}}TuringHeadController{{/code}} and directly set that field in the TODO part of the {{code language="none"}}execute{{/code}} method shown above.
110 -1. Use the resource set code shown in the EMF tutorial for loading model files (without the stand-alone part) in order to load the {{code language="none"}}modelFile{{/code}} in the {{code language="none"}}initialize{{/code}} method.
111 -1. Now you should be able to simulate models written in your textual syntax: start Eclipse, right-click a textual Turing Machine file (*.tuxt), select //Set Simulation File//, and run simulation in your Tape view using the correct controller.
112 -
113 -\\
52 +
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -3604669
1 +2982418
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/WS12EclPract/pages/3604669/Textual Modeling with Xtext
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/WS12EclPract/pages/2982418/Textual Modeling with Xtext