| h2(#Editors). Editors |
| |
| The four editors are all generated using "Xtext":../../org.eclipse.xtext.doc/contents/xtext.html, and so exhibit similar behavior to other Eclipse editors. |
| |
| The standard facilities are |
| * syntax coloring |
| * folding |
| * outline view |
| * hover text |
| * syntax validation |
| * semantic validation |
| |
| The following facilities have partial functionality |
| * go to definition |
| * content assist |
| * templates |
| * quick fixes |
| * find references |
| |
| The following facilities have little or no functionality |
| * rename element |
| * final validation |
| |
| h3. Syntax coloring |
| |
| The editors use similar colors to JDT. |
| * green for comments |
| * bold purple for keywords |
| * grey for numbers |
| * blue for strings |
| |
| Additionally |
| * italics for text referencing a definition |
| |
| References for which the name of the definition matches a keyword use italics in the same way as other cross references. Names of a definition matching a keyword use bold purple in the same way as keywords. |
| |
| The syntax coloring may changed using the *Window->Preferences->OCL* pages. |
| |
| h3. Validation |
| |
| Syntax errors are detected and offending text is underlined with accompanying annotations and problem markers. |
| |
| If there are no syntax errors, semantic validation is performed with similar feedback of problems. Semantic validation is not performed when there are syntax errors since a single syntax error many provoke many hundreds of semantic errors. These can make the original syntax error difficult to resolve. |
| |
| The use of the well-formedness rules for a final validation of the Abstract Syntax are not yet performed since repeated interpreted execution of many OCL constraints on a large model is a performance concern. This functionality will be activated once the Impact Analyzer has migrated to the pivot metamodel and the Java Code generator for OCL is functional. |
| |
| By default, the Xtext nature is not added to projects using OCL editors and so no builder runs in the background creating problem markers for OCL files. This is generally beneficial when you have many files for which the over-enthusiastic rebuilds waste build time, or experimental files for which the many errors clutter the Problem View. |
| |
| If your OCL is good quality, you may activate the Xtext nature and builder by selecting the project and then invoking *Configure->Add Xtext Nature*. |
| |
| h3. Hover Text |
| |
| Hover text has been implemented to provide feedback on the usage and type of expression terms. For instance hovering over the size operation in the example below reveals that it is an Operation for the Loan specialization of Collection . |
| |
| !{width:100%}images/1510-hovertext.png(Hover Text)! |
| |
| (Note that the Class specialization for Loan is incorrectly shown again as an Operation specialization.) |
| |
| h3. Content Assist |
| |
| Typing *Ctrl* and *Space* activates the Content Assist pop-up to offer suggestions as to what might be typed to the right of the cursor. |
| |
| The default Xtext functionality provides many useful suggestions, but does not always handle grammar ambiguities, and does not offer suggestions immediately following punctuation, so no content assist is provided at the end of: |
| |
| bc.. |
| self. |
| p. |
| |
| A simple workaround is to trick Xtext by providing an example continuation. Alternatives are offered for the continuation. So type a letter then reposition the cursor following the dot and then type *Ctrl* and *Space* |
| |
| !{width:100%}images/1510-contentassist.png(Content Assist)! |
| |
| h3. Code Templates |
| |
| Code templates are supported by Xtext but only one template for an OCL Standard Library has been defined. |
| |
| You may define your own templates. If you would like to contribute them, please raise a Bugzilla. |
| |
| h3. Open Declaration |
| |
| It is possible to navigate to a definition provided an editor is already open for the definition. |
| |
