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

Summary

Details

Page properties
Content
... ... @@ -48,5 +48,66 @@
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.
51 51  
52 -
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 +\\
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -2982418
1 +3604669
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/WS12EclPract/pages/2982418/Textual Modeling with Xtext
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/WS12EclPract/pages/3604669/Textual Modeling with Xtext