Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Updated and re-generated help. Images should now render fine. Source …

…code will be rendered a little bit smaller in the PDF.
  • Loading branch information...
commit 81d8500b8f6f099276b11eed2e066fd42ac7e3ad 1 parent 933f0b7
pfriese authored
Showing with 3,810 additions and 2,699 deletions.
  1. +11 −0 plugins/org.eclipse.xtext.doc/customBuild.xml
  2. +2 −2 plugins/org.eclipse.xtext.doc/doc/030-generator.textile
  3. +152 −1 plugins/org.eclipse.xtext.doc/doc/170-outline.textile
  4. +14 −0 plugins/org.eclipse.xtext.doc/doc/220-deploying-dsls.textile
  5. BIN  plugins/org.eclipse.xtext.doc/doc/images/sample_outline.jpg
  6. BIN  plugins/org.eclipse.xtext.doc/doc/images/sample_outline.png
  7. +1 −1  plugins/org.eclipse.xtext.doc/doc/xtext-index.txt
  8. +32 −25 plugins/org.eclipse.xtext.doc/help/Defaulttokens.html
  9. +37 −29 plugins/org.eclipse.xtext.doc/help/IDEconcepts.html
  10. +8 −7 plugins/org.eclipse.xtext.doc/help/MigrationSupport.html
  11. +21 −17 plugins/org.eclipse.xtext.doc/help/NewFeatures.html
  12. +10 −9 plugins/org.eclipse.xtext.doc/help/Overview.html
  13. +10 −9 plugins/org.eclipse.xtext.doc/help/RuntimeConcepts.html
  14. +26 −23 plugins/org.eclipse.xtext.doc/help/SetupwithinEclipseEquinox.html
  15. +36 −30 plugins/org.eclipse.xtext.doc/help/Xtend_based_apis.html
  16. +9 −8 plugins/org.eclipse.xtext.doc/help/concepts.html
  17. +67 −56 plugins/org.eclipse.xtext.doc/help/contentAssist.html
  18. +19 −16 plugins/org.eclipse.xtext.doc/help/dependencyInjection.html
  19. +87 −71 plugins/org.eclipse.xtext.doc/help/differences.html
  20. +76 −63 plugins/org.eclipse.xtext.doc/help/formatting.html
  21. +33 −32 plugins/org.eclipse.xtext.doc/help/fragmentProvider.html
  22. +8 −7 plugins/org.eclipse.xtext.doc/help/from_oaw_to_tmf.html
  23. +192 −151 plugins/org.eclipse.xtext.doc/help/generator.html
  24. +11 −8 plugins/org.eclipse.xtext.doc/help/grammarImport.html
  25. +405 −330 plugins/org.eclipse.xtext.doc/help/grammarLanguage.html
  26. +34 −26 plugins/org.eclipse.xtext.doc/help/grammarMixins.html
  27. BIN  plugins/org.eclipse.xtext.doc/help/images/sample_outline.jpg
  28. BIN  plugins/org.eclipse.xtext.doc/help/images/sample_outline.png
  29. +5 −4 plugins/org.eclipse.xtext.doc/help/index.html
  30. +1 −1  plugins/org.eclipse.xtext.doc/help/index.xml
  31. +7 −6 plugins/org.eclipse.xtext.doc/help/labelProvider.html
  32. +105 −82 plugins/org.eclipse.xtext.doc/help/linking.html
  33. +46 −39 plugins/org.eclipse.xtext.doc/help/metamodelInference.html
  34. +13 −12 plugins/org.eclipse.xtext.doc/help/migration_overview.html
  35. +7 −6 plugins/org.eclipse.xtext.doc/help/navigation.html
  36. +265 −7 plugins/org.eclipse.xtext.doc/help/outline.html
  37. +95 −98 plugins/org.eclipse.xtext.doc/help/scoping.html
  38. +52 −53 plugins/org.eclipse.xtext.doc/help/serialization.html
  39. +19 −16 plugins/org.eclipse.xtext.doc/help/templates.html
  40. +45 −33 plugins/org.eclipse.xtext.doc/help/validation.html
  41. +57 −51 plugins/org.eclipse.xtext.doc/help/valueconverter.html
  42. BIN  plugins/org.eclipse.xtext.doc/html/images/sample_outline.jpg
  43. BIN  plugins/org.eclipse.xtext.doc/html/images/sample_outline.png
  44. +1,695 −1,280 plugins/org.eclipse.xtext.doc/html/xtext.html
  45. BIN  plugins/org.eclipse.xtext.doc/manual/xtext.pdf
  46. +2 −2 plugins/org.eclipse.xtext.doc/styles/xmpp.xsl
  47. +95 −88 plugins/org.eclipse.xtext.doc/toc.xml
View
11 plugins/org.eclipse.xtext.doc/customBuild.xml
@@ -203,6 +203,7 @@
<param name="admon.graphics.extension" expression=".gif"/>
<param name="admon.textlabel" expression="0"/>
<param name="ulink.target" expression="_new"/>
+ <param name="ignore.image.scaling" expression="1"/>
</xslt>
</target>
@@ -212,6 +213,14 @@
<delete file="${build.dir}${file.separator}${document.name}.fo"/>
<mkdir dir="manual"/>
+ <!-- HACK! images should rather be copied to build/images -->
+ <copy todir="${basedir}">
+ <fileset dir="doc/">
+ <include name="images/**" />
+ </fileset>
+ </copy>
+
+
<xslt in="${build.dir}${file.separator}${document.name}.xml" extension="xml" out="${build.dir}${file.separator}${document.name}.fo" style="${document.pdf.stylesheet}">
<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>
@@ -236,6 +245,7 @@
<!-- Remove the resulting formatting object. This object isn't necessary in the
result of this build. -->
<delete file="${build.dir}${file.separator}${document.name}.fo" />
+ <delete dir="${basedir}/images" />
</target>
<target name="wikitext2eclipsehelp" depends="assemble" description="Generate Eclipse Help from textile">
@@ -277,6 +287,7 @@
location="${docbook.dir}${file.separator}html${file.separator}chunk.xsl"/>
</xmlcatalog>
<param name="header.rule" expression="1" />
+ <param name="ignore.image.scaling" expression="1" />
</xslt>
<delete file="${basedir}/xtext.html" />
</target>
View
4 plugins/org.eclipse.xtext.doc/doc/030-generator.textile
@@ -41,7 +41,7 @@ bc..
</x>
p. These couple of lines will, when interpreted by MWE, result in an object tree consisting of three instances of foo.Person:
-!images/family_tree.png!
+!{width:50%}images/family_tree.png!
The name of the root element can have an arbitrary name and doesn't matter, with one exception: If the name is <workflow/> and no class attribute is provided. It is assumed that an instance of @org.eclipse.emf.mwe.internal.core.Workflow@ shall be instantiated. This is due to the fact that this is the implementation of the root of the workflow model which we one usually uses when creating generator workflow configurations. However as you can see in the example above one can instantiate arbitrary Java object models. This is conceptually very close to the dependency injection and the XML language in the "Spring Framework":http://www.springframework.org.
@@ -79,7 +79,7 @@ An instance of Xtext's generator is configured with general information about sr
For each language configuration a URI pointing to its grammar file and the file extensions for the DSL must be provided.
In addition a language is configured with a list of ${org.eclipse.xtext.generator/src/org.eclipse.xtext.generator.IGeneratorFragment}s.
The whole generator is composed of theses fragments. We have fragments for generating parsers, one for the serializer, one for the EMF code, one for the outline view, etc.
-!images/generator-structure.png!
+!{width:50%}images/generator-structure.png!
h4. Generator Fragments
View
153 plugins/org.eclipse.xtext.doc/doc/170-outline.textile
@@ -1,4 +1,155 @@
h2(#outline). Outline View
-text
+Xtext provides an outline view to help you navigate your models. By default, it provides a hierarchical view on your model and allows you to sort tree elements alphabetically. Selecting an element in the outline will highlight the correpsonding element in the text editor. Users can choose to synchronize the outline with the editor selection by clicking the _Link with Editor_ button.
+
+!{width:50%}images/sample_outline.png!
+
+You can customize various aspects of the outline by providing implementation for its various interfaces. The following sections show how to customize the various aspects of the outline.
+
+h3. Influencing the outline structure
+
+In its default implementation, the outline view shows the containment hierarchy of your model. This should be sufficient in most cases. If you want to adjust the structure of the outline, i.e., by omitting a certain kind of node or by introducing additional (artificial / virtual) nodes, you customize the outline by implementing ${org.eclipse.xtext.ui.common/src/org.eclipse.xtext.ui.common.editor.outline.transformer.ISemanticModelTransformer}.
+
+The Xtext wizard creates an empty transformer class (@MyDslTransformer@) for your convenience. To transform the semantic model delivered by the Xtext parser, you need to provide transformation methods for each of the meta classes that are of interest:
+
+bc..
+public class MyDslTransformer extends AbstractDeclarativeSemanticModelTransformer {
+ /**
+ * This method will be called by naming convention:
+ * - method name must be createNode
+ * - first param: subclass of EObject
+ * - second param: ContentOutlineNode
+ */
+ public ContentOutlineNode createNode(Attribute semanticNode, ContentOutlineNode parentNode) {
+ ContentOutlineNode node = super.newOutlineNode(semanticNode, parentNode);
+ node.setLabel("special " + node.getLabel());
+ return node;
+ }
+
+ public ContentOutlineNode createNode(Property semanticNode, ContentOutlineNode parentNode) {
+ ContentOutlineNode node = super.newOutlineNode(semanticNode, parentNode);
+ node.setLabel("pimped " + node.getLabel());
+ return node;
+ }
+
+/**
+ * This method will be called by naming convention:
+ * - method name must be getChildren
+ * - first param: subclass of EObject
+ */
+ public List<EObject> getChildren(Attribute attribute) {
+ return attribute.eContents();
+ }
+
+ public List<EObject> getChildren(Property property) {
+ return NO_CHILDREN;
+ }
+ }
+
+
+p. To make sure Xtext picks up your new outline transformer, you have to register your implementation with your UI module:
+
+bc..
+public class MyDslUiModule extends AbstractXtextUiModule {
+
+ @Override
+ public Class<? extends ISemanticModelTransformer> bindISemanticModelTransformer() {
+ return MyDslTransformer.class;
+ }
+ ...
+}
+
+
+h3. Filtering
+
+Often, you want to allow users to filter the contents of the outline to make it easier to concentrate on the relevant aspects of the model. To add filtering capabilities to your outline, you need to add ${org.eclipse.xtext.ui.common/src/org.eclipse.xtext.ui.common.editor.outline.actions.AbstractFilterAction}s to the outline. Actions can be contributed by implementing and registering a ${org.eclipse.xtext.ui.common/src/org.eclipse.xtext.ui.common.editor.outline.actions.DeclarativeActionBarContributor}.
+
+To register a @DeclarativeActionBarContributor@, add the following lines to your @MyDslUiModule@ class:
+
+bc..
+/**
+ * Use this class to register components to be used within the IDE.
+ */
+public class MyDslUiModule extends org.xtext.example.AbstractMyDslUiModule {
+
+ ...
+
+ @Override
+ public Class<? extends IActionBarContributor> bindIActionBarContributor() {
+ return MyDslActionBarContributor.class;
+ }
+}
+
+p. The action bar contributor will look like this:
+
+bc..
+public class MyDslActionBarContributor extends DeclarativeActionBarContributor {
+ public Action addFilterParserRulesToolbarAction(XtextContentOutlinePage page) {
+ return new FilterFooAction(page);
+ }
+}
+
+p. Filter actions must extend @AbstractFilterAction@ (this ensures that the action toggle state is handled correctly):
+
+bc..
+import org.eclipse.jface.viewers.ViewerFilter;
+import org.eclipse.xtext.ui.common.editor.outline.XtextContentOutlinePage;
+import org.eclipse.xtext.ui.common.editor.outline.actions.AbstractFilterAction;
+import org.eclipse.xtext.xtext.ui.Activator;
+
+public class FilterFooAction extends AbstractFilterAction {
+
+ public FilterFooAction(XtextContentOutlinePage outlinePage) {
+ super("Filter Foo", outlinePage);
+ setToolTipText("Show / hide foo");
+ setDescription("Show / hide foo");
+ setImageDescriptor(Activator.getImageDescriptor("icons/fltr_foo.gif"));
+ setDisabledImageDescriptor(Activator.getImageDescriptor("icons/fltr_foo.gif"));
+ }
+
+ @Override
+ protected String getToggleId() {
+ return "FilterFooAction.isChecked";
+ }
+
+ @Override
+ protected ViewerFilter createFilter() {
+ return new FooOutlineFilter();
+ }
+
+}
+
+p. The filtering itself will be performed by @FooOutlineFilter@:
+
+bc..
+import org.eclipse.emf.ecore.EClass;
+import org.eclipse.jface.viewers.Viewer;
+import org.eclipse.jface.viewers.ViewerFilter;
+import org.eclipse.xtext.XtextPackage;
+import org.eclipse.xtext.ui.common.editor.outline.ContentOutlineNode;
+
+public class FooOutlineFilter extends ViewerFilter {
+
+ @Override
+ public boolean select(Viewer viewer, Object parentElement, Object element) {
+ if ((parentElement != null) && (parentElement instanceof ContentOutlineNode)) {
+ ContentOutlineNode parentNode = (ContentOutlineNode) parentElement;
+ EClass clazz = parentNode.getClazz();
+ if (clazz.equals(MyDslPackage.Literals.ATTRIBUTE)) {
+ return false;
+ }
+ }
+ return true;
+ }
+
+}
+
+
+h3. Context menus
+
+(stay tuned)
+
+h3. Sorting
+
+(stay tuned)
View
14 plugins/org.eclipse.xtext.doc/doc/220-deploying-dsls.textile
@@ -0,0 +1,14 @@
+
+h1(#deploying_dsls). Deploying DSLs
+
+Deploying a DSL is a straightforward process - all you need to know is how to build Eclipse Feature Projects. For convenience, here is a short overview to get you started:
+
+h2. Prepare your DSL projects
+
+If you use custom icons in your DSL, please make sure to include the @/icons@ folder (or whatever you called the folder with your custom icons) in the binary build of the UI bundle of your DSL. Otherwise, your icons will not show up in the deployed DSL editor.
+
+h2. Creating a Feature for your DSL
+
+h2. Creating an Update Site for your DSL
+
+
View
BIN  plugins/org.eclipse.xtext.doc/doc/images/sample_outline.jpg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  plugins/org.eclipse.xtext.doc/doc/images/sample_outline.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
2  plugins/org.eclipse.xtext.doc/doc/xtext-index.txt
@@ -24,4 +24,4 @@
190-formatting.textile
200-Appendix.textile
-210-migrating-from-oaw.textile
+210-migrating-from-oaw.textile
View
57 plugins/org.eclipse.xtext.doc/help/Defaulttokens.html
@@ -1,37 +1,44 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Default tokens</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="Overview.html" title="Overview"/>
-<link rel="prev" href="grammarMixins.html" title="Grammar Mixins"/>
-<link rel="next" href="generator.html" title="The Generator"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="Overview.html" title="Overview">
+<link rel="prev" href="grammarMixins.html" title="Grammar Mixins">
+<link rel="next" href="generator.html" title="The Generator">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Default tokens</h1>
<p>Xtext is shipped with a default set of predefined, reasonable and often required terminal rules. This grammar is defined as follows:</p>
<div class="literallayout">
<p>
-<code class="code">grammar org.eclipse.xtext.common.Terminals <br/>
-   hidden(WS, ML_COMMENT, SL_COMMENT)<br/>
-<br/>
- import "http://www.eclipse.org/emf/2002/Ecore" as ecore<br/>
-<br/>
- terminal ID : <br/>
-   '^'?('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')* ;<br/>
- terminal INT returns ecore::EInt: ('0'..'9')+ ;<br/>
- terminal STRING : <br/>
-   '"' ( '\\' ('b'|'t'|'n'|'f'|'r'|'"'|"'"|'\\') | !('\\'|'"') )* '"' |<br/>
-   "'" ( '\\' ('b'|'t'|'n'|'f'|'r'|'"'|"'"|'\\') | !('\\'|"'") )* "'"<br/>
-   ; <br/>
- terminal ML_COMMENT : '/*' -&gt; '*/' ;<br/>
- terminal SL_COMMENT  : '//' !('\n'|'\r')* ('\r'? '\n')? ;<br/>
-<br/>
- terminal WS : (' '|'\t'|'\r'|'\n')+ ;<br/>
-<br/>
- terminal ANY_OTHER: . ;<br/>
-<br/>
+<code class="code">grammar&nbsp;org.eclipse.xtext.common.Terminals&nbsp;<br>
+&nbsp;&nbsp;&nbsp;hidden(WS,&nbsp;ML_COMMENT,&nbsp;SL_COMMENT)<br>
+
+<br>
+&nbsp;import&nbsp;"http://www.eclipse.org/emf/2002/Ecore"&nbsp;as&nbsp;ecore<br>
+
+<br>
+&nbsp;terminal&nbsp;ID&nbsp;:&nbsp;<br>
+&nbsp;&nbsp;&nbsp;'^'?('a'..'z'|'A'..'Z'|'_')&nbsp;('a'..'z'|'A'..'Z'|'_'|'0'..'9')*&nbsp;;<br>
+&nbsp;terminal&nbsp;INT&nbsp;returns&nbsp;ecore::EInt:&nbsp;('0'..'9')+&nbsp;;<br>
+&nbsp;terminal&nbsp;STRING :&nbsp;<br>
+&nbsp;&nbsp;&nbsp;'"'&nbsp;(&nbsp;'\\'&nbsp;('b'|'t'|'n'|'f'|'r'|'"'|"'"|'\\')&nbsp;|&nbsp;!('\\'|'"')&nbsp;)*&nbsp;'"'&nbsp;|<br>
+&nbsp;&nbsp;&nbsp;"'"&nbsp;(&nbsp;'\\'&nbsp;('b'|'t'|'n'|'f'|'r'|'"'|"'"|'\\')&nbsp;|&nbsp;!('\\'|"'")&nbsp;)*&nbsp;"'"<br>
+&nbsp;&nbsp;&nbsp;;&nbsp;<br>
+&nbsp;terminal&nbsp;ML_COMMENT :&nbsp;'/*'&nbsp;-&gt;&nbsp;'*/'&nbsp;;<br>
+&nbsp;terminal&nbsp;SL_COMMENT&nbsp; :&nbsp;'//'&nbsp;!('\n'|'\r')*&nbsp;('\r'?&nbsp;'\n')?&nbsp;;<br>
+
+<br>
+&nbsp;terminal&nbsp;WS :&nbsp;('&nbsp;'|'\t'|'\r'|'\n')+&nbsp;;<br>
+
+<br>
+&nbsp;terminal&nbsp;ANY_OTHER: .&nbsp;;<br>
+
+<br>
+
</code>
</p>
</div>
View
66 plugins/org.eclipse.xtext.doc/help/IDEconcepts.html
@@ -1,49 +1,57 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>IDE concepts</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="index.html" title="Xtext User Guide"/>
-<link rel="prev" href="fragmentProvider.html" title="Fragment Provider (referencing Xtext models from other EMF artifacts)"/>
-<link rel="next" href="labelProvider.html" title="Label Provider"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="index.html" title="Xtext User Guide">
+<link rel="prev" href="fragmentProvider.html" title="Fragment Provider (referencing Xtext models from other EMF artifacts)">
+<link rel="next" href="labelProvider.html" title="Label Provider">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">IDE concepts</h1>
<p>For the following part we will refer to a concrete example grammar in order to explain certain aspect of the UI more clearly. The used example grammar is as follows:</p>
<div class="literallayout">
<p>
-<code class="code">grammar org.eclipse.text.documentation.Sample <br/>
-    with org.eclipse.xtext.common.Terminals<br/>
-<br/>
-generate gen 'http://www.eclipse.org/xtext/documentation/Sample' as gen<br/>
-<br/>
-Model :<br/>
-  "model" intAttribute=INT (stringDescription=STRING)? "{" <br/>
-     (rules += AbstractRule)* <br/>
-  "}" <br/>
-;<br/>
-<br/>
-AbstractRule:<br/>
-  RuleA | RuleB<br/>
-;<br/>
-<br/>
-RuleA :<br/>
-   "RuleA" "(" name = ID ")" ;<br/>
-<br/>
-RuleB return gen::CustomType:<br/>
-   "RuleB" "(" ruleA = [RuleA] ")" ;<br/>
-<br/>
+<code class="code">grammar&nbsp;org.eclipse.text.documentation.Sample&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;with&nbsp;org.eclipse.xtext.common.Terminals<br>
+
+<br>
+generate&nbsp;gen&nbsp;'http://www.eclipse.org/xtext/documentation/Sample'&nbsp;as&nbsp;gen<br>
+
+<br>
+Model&nbsp;:<br>
+&nbsp;&nbsp;"model"&nbsp;intAttribute=INT&nbsp;(stringDescription=STRING)?&nbsp;"{"&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(rules&nbsp;+=&nbsp;AbstractRule)*&nbsp;<br>
+&nbsp;&nbsp;"}"&nbsp;<br>
+;<br>
+
+<br>
+AbstractRule:<br>
+&nbsp;&nbsp;RuleA&nbsp;|&nbsp;RuleB<br>
+;<br>
+
+<br>
+RuleA&nbsp;:<br>
+&nbsp;&nbsp;&nbsp;"RuleA"&nbsp;"("&nbsp;name&nbsp;=&nbsp;ID&nbsp;")"&nbsp;;<br>
+
+<br>
+RuleB&nbsp;return&nbsp;gen::CustomType:<br>
+&nbsp;&nbsp;&nbsp;"RuleB"&nbsp;"("&nbsp;ruleA&nbsp;=&nbsp;[RuleA]&nbsp;")"&nbsp;;<br>
+
+<br>
+
</code>
</p>
</div>
-<p/>
+<p></p>
<div class="section" title="Managing Concurrency">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both">
-<a name="concurrency"/>Managing Concurrency</h2>
+<a name="concurrency"></a>Managing Concurrency</h2>
</div>
</div>
</div>
View
15 plugins/org.eclipse.xtext.doc/help/MigrationSupport.html
@@ -1,15 +1,16 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Migration Support</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF"/>
-<link rel="prev" href="NewFeatures.html" title="New Features"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF">
+<link rel="prev" href="NewFeatures.html" title="New Features">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Migration Support</h1>
-<p>In this document we tried to explain why we decided to change some aspects of Xtext&#8217;s architecture. We consider most changes as minor but when it comes to scopes you will face a conceptual enhancement that did not exist in oAW Xtext. We tried to explain why it is not easily possible to come up with an adapter for scoping.</p>
-<p>That said you might not have the time to do the migration and wished to have advice for migrating, especially from oAW linking to TMF linking. You&#8217;re welcome to ask any questions in the newsgroup and we&#8217;ll try to help you as much as possible in order to get your projects migrated. Also, if you don&#8217;t want to do the migration yourself we (itemis AG) can do the work for you or help you with that. </p>
+<p>In this document we tried to explain why we decided to change some aspects of Xtext&rsquo;s architecture. We consider most changes as minor but when it comes to scopes you will face a conceptual enhancement that did not exist in oAW Xtext. We tried to explain why it is not easily possible to come up with an adapter for scoping.</p>
+<p>That said you might not have the time to do the migration and wished to have advice for migrating, especially from oAW linking to TMF linking. You&rsquo;re welcome to ask any questions in the newsgroup and we&rsquo;ll try to help you as much as possible in order to get your projects migrated. Also, if you don&rsquo;t want to do the migration yourself we (itemis AG) can do the work for you or help you with that. </p>
</body>
</html>
View
38 plugins/org.eclipse.xtext.doc/help/NewFeatures.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>New Features</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF"/>
-<link rel="prev" href="differences.html" title="Differences"/>
-<link rel="next" href="MigrationSupport.html" title="Migration Support"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF">
+<link rel="prev" href="differences.html" title="Differences">
+<link rel="next" href="MigrationSupport.html" title="Migration Support">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">New Features</h1>
@@ -16,7 +17,7 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">New Features</h1>
<div>
<div>
<h3 class="title">
-<a name="DependencyInjectionwithGoogleGuice"/>Dependency Injection with Google Guice</h3>
+<a name="DependencyInjectionwithGoogleGuice"></a>Dependency Injection with Google Guice</h3>
</div>
</div>
</div>
@@ -29,7 +30,7 @@ <h3 class="title">
<div>
<div>
<h3 class="title">
-<a name="ImprovementsonGrammarLevel"/>Improvements on Grammar Level</h3>
+<a name="ImprovementsonGrammarLevel"></a>Improvements on Grammar Level</h3>
</div>
</div>
</div>
@@ -37,13 +38,15 @@ <h3 class="title">
<a class="link" href="grammarLanguage.html" title="The Grammar Language">grammar language</a> to understand the details about all the improvements that have been implemented.
</p>
<p>
- <a class="link" href="">Grammar mixins</a> allow you to extend existing languages and change their concrete and abstract syntax. However the abstract syntax (i.e. the Ecore model) can only be extended. This allows you to reuse existing validations, code generators, interpreters or other code which has been written against those types.
+
+<a class="link" href="">Grammar mixins</a> allow you to extend existing languages and change their concrete and abstract syntax. However the abstract syntax (i.e. the Ecore model) can only be extended. This allows you to reuse existing validations, code generators, interpreters or other code which has been written against those types.
</p>
-<p>In oAW Xtext common terminals like ID, INT, STRING, ML_COMMENT, SL_SOMMENT and WS (whitespace) were hard coded into the grammar language and couldn&#8217;t be removed and hardly overridden. In TMF Xtext these terminals are imported through the newly introduced grammar mixin mechanism from the shipped grammar
- <code class="code">org.eclipse.xtext.common.Terminals</code> per default. This means that they are still there but reside in a libraries now. You don&#8217;t have to use them and you can come up with your own set of reusable rules.
+<p>In oAW Xtext common terminals like ID, INT, STRING, ML_COMMENT, SL_SOMMENT and WS (whitespace) were hard coded into the grammar language and couldn&rsquo;t be removed and hardly overridden. In TMF Xtext these terminals are imported through the newly introduced grammar mixin mechanism from the shipped grammar
+ <code class="code">org.eclipse.xtext.common.Terminals</code> per default. This means that they are still there but reside in a libraries now. You don&rsquo;t have to use them and you can come up with your own set of reusable rules.
</p>
<p>
- <a class="link" href="">Reusing existing Ecore models</a> in oAW Xtext didn&#8217;t work well and we communicated this by flagging this feature as &#8216;experimental&#8217;. In TMF Xtext importing existing Ecore models is fully supported. Moreover, it is possible to import a couple of different EPackages and generate some at the same time, so that the generated Ecore models extend or refer to the existing Ecore models.
+
+<a class="link" href="">Reusing existing Ecore models</a> in oAW Xtext didn&rsquo;t work well and we communicated this by flagging this feature as &lsquo;experimental&rsquo;. In TMF Xtext importing existing Ecore models is fully supported. Moreover, it is possible to import a couple of different EPackages and generate some at the same time, so that the generated Ecore models extend or refer to the existing Ecore models.
</p>
<p>The grammar language gained one new concept that is of great value when writing left-factored grammars (e.g. expressions). With actions one can do minor AST rewritings within a rule to overcome degenerated ASTs. You will find an
<a class="link" href="">in-depth explanation of actions</a> in the dedicated chapter in the reference documentation.
@@ -54,7 +57,7 @@ <h3 class="title">
<div>
<div>
<h3 class="title">
-<a name="Finegrainedcontrolforvalidation"/>Fine-grained control for validation</h3>
+<a name="Finegrainedcontrolforvalidation"></a>Fine-grained control for validation</h3>
</div>
</div>
</div>
@@ -77,13 +80,14 @@ <h3 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  context Entity#name ERROR "Name should start with a capital "+this.name+"." :<br/>
-    this.name.toFirstUpper() == this.name;<br/>
+<br>
+&nbsp;&nbsp;context&nbsp;Entity#name&nbsp;ERROR&nbsp;"Name&nbsp;should&nbsp;start&nbsp;with&nbsp;a&nbsp;capital&nbsp;"+this.name+"."&nbsp;:<br>
+&nbsp;&nbsp;&nbsp;&nbsp;this.name.toFirstUpper()&nbsp;==&nbsp;this.name;<br>
+
</code>
</p>
</div>
-<p>If you add the name of a feature prepended by a hash (&#8216;#&#8217;) in Check, the editor will only mark the value of the feature (name), not the whole object (Entity). Both concepts, control over validation time as well as pointing to a specific feature, complement one another in Check and Java based validation.</p>
+<p>If you add the name of a feature prepended by a hash (&lsquo;#&rsquo;) in Check, the editor will only mark the value of the feature (name), not the whole object (Entity). Both concepts, control over validation time as well as pointing to a specific feature, complement one another in Check and Java based validation.</p>
</div>
</body>
</html>
View
19 plugins/org.eclipse.xtext.doc/help/Overview.html
@@ -1,21 +1,22 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Overview</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="index.html" title="Xtext User Guide"/>
-<link rel="prev" href="index.html" title="Xtext User Guide"/>
-<link rel="next" href="concepts.html" title="Xtext concepts from a bird&#8217;s eye view"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="index.html" title="Xtext User Guide">
+<link rel="prev" href="index.html" title="Xtext User Guide">
+<link rel="next" href="concepts.html" title="Xtext concepts from a bird&rsquo;s eye view">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Overview</h1>
-<div class="section" title="What&#8217;s Xtext?">
+<div class="section" title="What&rsquo;s Xtext?">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both">
-<a name="WhatsXtext"/>What&#8217;s Xtext?</h2>
+<a name="WhatsXtext"></a>What&rsquo;s Xtext?</h2>
</div>
</div>
</div>
@@ -64,7 +65,7 @@ <h2 class="title" style="clear: both">
</ul>
</div>
<p>The generated artifacts are wired up through
- <a class="ulink" href="http://code.google.com/p/google-guice/" target="_new">Google Guice</a>, a dependency injection framework which makes it easy to exchange certain functionality in a non-invasive manner. For example if you don&#8217;t like the default code assistant implementation, all you need to do is to come up with an alternative implementation of the corresponding service and configure it via
+ <a class="ulink" href="http://code.google.com/p/google-guice/" target="_new">Google Guice</a>, a dependency injection framework which makes it easy to exchange certain functionality in a non-invasive manner. For example if you don&rsquo;t like the default code assistant implementation, all you need to do is to come up with an alternative implementation of the corresponding service and configure it via
<a class="link" href="dependencyInjection.html" title="Dependency Injection in Xtext with Google Guice">dependency injection</a>.
</p>
</div>
View
19 plugins/org.eclipse.xtext.doc/help/RuntimeConcepts.html
@@ -1,21 +1,22 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Runtime Concepts</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="index.html" title="Xtext User Guide"/>
-<link rel="prev" href="dependencyInjection.html" title="Dependency Injection in Xtext with Google Guice"/>
-<link rel="next" href="SetupwithinEclipseEquinox.html" title="Setup within Eclipse / Equinox"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="index.html" title="Xtext User Guide">
+<link rel="prev" href="dependencyInjection.html" title="Dependency Injection in Xtext with Google Guice">
+<link rel="next" href="SetupwithinEclipseEquinox.html" title="Setup within Eclipse / Equinox">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Runtime Concepts</h1>
<p>TMF Xtext itself and every language infrastructure developed with TMF Xtext is configured and wired-up using dependency injection (DI).</p>
-<p>We use Google Guice as the underlying framework, and haven&#8217;t built much on top of it as it pretty much does what we need.
+<p>We use Google Guice as the underlying framework, and haven&rsquo;t built much on top of it as it pretty much does what we need.
So instead of describing how google guice works, we refer to the website, where additional information can be found:
<a class="ulink" href="http://code.google.com/p/google-guice/" target="_new">http://code.google.com/p/google-guice/</a>.
</p>
-<p>Using DI allows everyone to set up and change all components. This does not mean that everything which gets configured using DI (we use it a lot) is automatically public API. But we don&#8217;t forbid use of non-public API, as we think you should decide, if you want to rely on stable API only or use things which might be changed (further enhanced ;-)) in future. See
+<p>Using DI allows everyone to set up and change all components. This does not mean that everything which gets configured using DI (we use it a lot) is automatically public API. But we don&rsquo;t forbid use of non-public API, as we think you should decide, if you want to rely on stable API only or use things which might be changed (further enhanced ;-)) in future. See
<a class="link" href="">Xtext API Documentation</a>.
</p>
<div class="section" title="Runtime setup (ISetup)">
@@ -23,7 +24,7 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Runtime Concepts</h1
<div>
<div>
<h2 class="title" style="clear: both">
-<a name="RuntimesetupISetup"/>Runtime setup (ISetup)</h2>
+<a name="RuntimesetupISetup"></a>Runtime setup (ISetup)</h2>
</div>
</div>
</div>
View
49 plugins/org.eclipse.xtext.doc/help/SetupwithinEclipseEquinox.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Setup within Eclipse / Equinox</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="RuntimeConcepts.html" title="Runtime Concepts"/>
-<link rel="prev" href="RuntimeConcepts.html" title="Runtime Concepts"/>
-<link rel="next" href="validation.html" title="Validation"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="RuntimeConcepts.html" title="Runtime Concepts">
+<link rel="prev" href="RuntimeConcepts.html" title="Runtime Concepts">
+<link rel="next" href="validation.html" title="Validation">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Setup within Eclipse / Equinox</h1>
@@ -17,23 +18,25 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Setup within Eclipse
<div class="literallayout">
<p>
<code class="code">
-<br/>
-&lt;extension<br/>
-  point="org.eclipse.ui.editors"&gt;<br/>
-  &lt;editor<br/>
-    class="&lt;MyLanguageName&gt;ExecutableExtensionFactory:<br/>
-      org.eclipse.xtext.ui.core.editor.XtextEditor"<br/>
-    contributorClass=<br/>
-      "org.eclipse.ui.editors.text.TextEditorActionContributor"<br/>
-    default="true"<br/>
-    extensions="ecoredsl"<br/>
-    id="org.eclipse.xtext.example.EcoreDsl"<br/>
-    name="EcoreDsl Editor"&gt;<br/>
-  &lt;/editor&gt;<br/>
-&lt;/extension&gt;<br/>
-  <br/>
-  <br/>
-<br/>
+<br>
+&lt;extension<br>
+&nbsp;&nbsp;point="org.eclipse.ui.editors"&gt;<br>
+&nbsp;&nbsp;&lt;editor<br>
+&nbsp;&nbsp;&nbsp;&nbsp;class="&lt;MyLanguageName&gt;ExecutableExtensionFactory:<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;org.eclipse.xtext.ui.core.editor.XtextEditor"<br>
+&nbsp;&nbsp;&nbsp;&nbsp;contributorClass=<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"org.eclipse.ui.editors.text.TextEditorActionContributor"<br>
+&nbsp;&nbsp;&nbsp;&nbsp;default="true"<br>
+&nbsp;&nbsp;&nbsp;&nbsp;extensions="ecoredsl"<br>
+&nbsp;&nbsp;&nbsp;&nbsp;id="org.eclipse.xtext.example.EcoreDsl"<br>
+&nbsp;&nbsp;&nbsp;&nbsp;name="EcoreDsl&nbsp;Editor"&gt;<br>
+&nbsp;&nbsp;&lt;/editor&gt;<br>
+&lt;/extension&gt;<br>
+&nbsp;&nbsp;<br>
+&nbsp;&nbsp;<br>
+
+<br>
+
</code>
</p>
</div>
View
66 plugins/org.eclipse.xtext.doc/help/Xtend_based_apis.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Where are the Xtend-based APIs?</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF"/>
-<link rel="prev" href="migration_overview.html" title="Migration overview"/>
-<link rel="next" href="differences.html" title="Differences"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF">
+<link rel="prev" href="migration_overview.html" title="Migration overview">
+<link rel="next" href="differences.html" title="Differences">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Where are the Xtend-based APIs?</h1>
@@ -20,7 +21,7 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Where are the Xtend-
<div>
<div>
<h3 class="title">
-<a name="Xtend_is_hard_to_debug"/>Xtend is hard to debug</h3>
+<a name="Xtend_is_hard_to_debug"></a>Xtend is hard to debug</h3>
</div>
</div>
</div>
@@ -32,12 +33,12 @@ <h3 class="title">
<div>
<div>
<h3 class="title">
-<a name="Xtend_is_slow"/>Xtend is slow</h3>
+<a name="Xtend_is_slow"></a>Xtend is slow</h3>
</div>
</div>
</div>
-<p>But the problematic debugging in the context of Xtext was not the main reason why there are no Xtend-based APIs beside Check in TMF Xtext. The main reason is that Xtend is too slow to be evaluated &#8220;inside&#8221; the editor again and again while you type.
- While Xtend&#8217;s performance is sufficient when run in a code generator, it is just too slow to be executed on keystroke (or 500ms after the last keystroke, which is when the reconciler reparses, links and validates the model). Xtend is relatively slow, because it supports polymorphic dispatch (the cool feature mentioned above), which means that for each invocation it matches at runtime which function is the best match and it has to do so on each call. Also Xtend supports a pluggable typesystem, where you can adapt to other existing type systems such as JavaBeans or Ecore. This is very powerful and flexible but introduces another indirection layer. Last but not least the code is interpreted and not compiled. The price we pay for all these nice features is reduced performance.</p>
+<p>But the problematic debugging in the context of Xtext was not the main reason why there are no Xtend-based APIs beside Check in TMF Xtext. The main reason is that Xtend is too slow to be evaluated &ldquo;inside&rdquo; the editor again and again while you type.
+ While Xtend&rsquo;s performance is sufficient when run in a code generator, it is just too slow to be executed on keystroke (or 500ms after the last keystroke, which is when the reconciler reparses, links and validates the model). Xtend is relatively slow, because it supports polymorphic dispatch (the cool feature mentioned above), which means that for each invocation it matches at runtime which function is the best match and it has to do so on each call. Also Xtend supports a pluggable typesystem, where you can adapt to other existing type systems such as JavaBeans or Ecore. This is very powerful and flexible but introduces another indirection layer. Last but not least the code is interpreted and not compiled. The price we pay for all these nice features is reduced performance.</p>
<p>In addition to these scalability problems we have designed some core APIs (e.g. scopes) around the idea of Iterables, which allows for lazy resolution of elements. As Xtend does not know the concept of Iterators you would have to work with lists all the time. Copying collections over and over again is far more expensive than chaining Iterables through filters and transformers like we do with Google Collections in TMF Xtext.</p>
</div>
<div class="section" title="Convenient Java">
@@ -45,7 +46,7 @@ <h3 class="title">
<div>
<div>
<h3 class="title">
-<a name="Convenient_Java"/>Convenient Java</h3>
+<a name="Convenient_Java"></a>Convenient Java</h3>
</div>
</div>
</div>
@@ -62,23 +63,28 @@ <h3 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-public class DomainModelLabelProvider extends DefaultLabelProvider {<br/>
-<br/>
-  String label(Entity e) {<br/>
-    return e.getName();<br/>
-  }<br/>
-<br/>
-  String image(Property p) {<br/>
-    return p.isMultiValue() ? "complexProperty.gif": "simpleProperty.gif";<br/>
-  }<br/>
-<br/>
-  String image(Entity e) {<br/>
-    return "entity.gif";<br/>
-  }<br/>
-<br/>
-}<br/>
-  <br/>
+<br>
+public&nbsp;class&nbsp;DomainModelLabelProvider&nbsp;extends&nbsp;DefaultLabelProvider&nbsp;{<br>
+
+<br>
+&nbsp;&nbsp;String&nbsp;label(Entity&nbsp;e)&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;e.getName();<br>
+&nbsp;&nbsp;}<br>
+
+<br>
+&nbsp;&nbsp;String&nbsp;image(Property&nbsp;p)&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;p.isMultiValue()&nbsp;?&nbsp;"complexProperty.gif":&nbsp;"simpleProperty.gif";<br>
+&nbsp;&nbsp;}<br>
+
+<br>
+&nbsp;&nbsp;String&nbsp;image(Entity&nbsp;e)&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;"entity.gif";<br>
+&nbsp;&nbsp;}<br>
+
+<br>
+}<br>
+&nbsp;&nbsp;<br>
+
</code>
</p>
</div>
@@ -89,12 +95,12 @@ <h3 class="title">
<div>
<div>
<h3 class="title">
-<a name="conclusion"/>Conclusion</h3>
+<a name="conclusion"></a>Conclusion</h3>
</div>
</div>
</div>
<p>Just to get it right, Xtend is a very powerful language and we still use it for its main purpose: code generation and model transformation. The whole generator in TMF Xtext is written in Xpand and Xtend and its performance is at least in our experience sufficient for that use case. Actually we were able to increase the runtime performance of Xpand by about 60% for the Galileo release of M2T Xpand. But still, live execution in the IDE and on typing is very critical and one has to think about every millisecond in this area. </p>
-<p>As an alternative to the Java APIs we also considered other JVM languages. We like static typing and think it is especially important when processing typed models (which evolve heavily). That&#8217;s why Groovy or JRuby were no alternatives. Using Scala would have been a very good match, but we didn&#8217;t want to require knowledge of Scala so we didn&#8217;t use it and stuck to Java. </p>
+<p>As an alternative to the Java APIs we also considered other JVM languages. We like static typing and think it is especially important when processing typed models (which evolve heavily). That&rsquo;s why Groovy or JRuby were no alternatives. Using Scala would have been a very good match, but we didn&rsquo;t want to require knowledge of Scala so we didn&rsquo;t use it and stuck to Java. </p>
</div>
</body>
</html>
View
17 plugins/org.eclipse.xtext.doc/help/concepts.html
@@ -1,15 +1,16 @@
<html>
<head>
-<title>Xtext concepts from a bird&#8217;s eye view</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="Overview.html" title="Overview"/>
-<link rel="prev" href="Overview.html" title="Overview"/>
-<link rel="next" href="grammarLanguage.html" title="The Grammar Language"/>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Xtext concepts from a bird&rsquo;s eye view</title>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="Overview.html" title="Overview">
+<link rel="prev" href="Overview.html" title="Overview">
+<link rel="next" href="grammarLanguage.html" title="The Grammar Language">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Xtext concepts from a bird&#8217;s eye view</h1>
+<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Xtext concepts from a bird&rsquo;s eye view</h1>
<p>text</p>
</body>
</html>
View
123 plugins/org.eclipse.xtext.doc/help/contentAssist.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Content Assist</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="IDEconcepts.html" title="IDE concepts"/>
-<link rel="prev" href="labelProvider.html" title="Label Provider"/>
-<link rel="next" href="templates.html" title="Template Proposals"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="IDEconcepts.html" title="IDE concepts">
+<link rel="prev" href="labelProvider.html" title="Label Provider">
+<link rel="next" href="templates.html" title="Template Proposals">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Content Assist</h1>
@@ -25,7 +26,8 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Content Assist</h1>
<code class="code">src</code>-folder of the
<code class="code">ui</code> project
<code class="code">ProposalProvider</code>
- </p>
+
+</p>
</li>
</ul>
</div>
@@ -37,28 +39,31 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Content Assist</h1>
<div>
<div>
<h3 class="title">
-<a name="ProposalProvider"/>ProposalProvider</h3>
+<a name="ProposalProvider"></a>ProposalProvider</h3>
</div>
</div>
</div>
<div class="literallayout">
<p>
-<code class="code">public void complete[TypeName]_[FeatureName](<br/>
-  EObject model, <br/>
-  Assignment assignment, <br/>
-  ContentAssistContext context, <br/>
-  ICompletionProposalAcceptor acceptor) {<br/>
-  // clients may override<br/>
-}<br/>
-<br/>
-public void complete_[RuleName](<br/>
-  EObject model, <br/>
-  RuleCall ruleCall, <br/>
-  ContentAssistContext context, <br/>
-  ICompletionProposalAcceptor acceptor) {<br/>
-  // clients may override<br/>
-}<br/>
-<br/>
+<code class="code">public&nbsp;void&nbsp;complete[TypeName]_[FeatureName](<br>
+&nbsp;&nbsp;EObject&nbsp;model,&nbsp;<br>
+&nbsp;&nbsp;Assignment&nbsp;assignment,&nbsp;<br>
+&nbsp;&nbsp;ContentAssistContext&nbsp;context,&nbsp;<br>
+&nbsp;&nbsp;ICompletionProposalAcceptor&nbsp;acceptor)&nbsp;{<br>
+&nbsp;&nbsp;//&nbsp;clients&nbsp;may&nbsp;override<br>
+}<br>
+
+<br>
+public&nbsp;void&nbsp;complete_[RuleName](<br>
+&nbsp;&nbsp;EObject&nbsp;model,&nbsp;<br>
+&nbsp;&nbsp;RuleCall&nbsp;ruleCall,&nbsp;<br>
+&nbsp;&nbsp;ContentAssistContext&nbsp;context,&nbsp;<br>
+&nbsp;&nbsp;ICompletionProposalAcceptor&nbsp;acceptor)&nbsp;{<br>
+&nbsp;&nbsp;//&nbsp;clients&nbsp;may&nbsp;override<br>
+}<br>
+
+<br>
+
</code>
</p>
</div>
@@ -68,49 +73,55 @@ <h3 class="title">
<p>Clients who want to customize the behavior may override the methods from the
<code class="code">AbstractProposalProvider</code> or in turn introduce new methods with specialized parameters. The framework dispatches method calls according to the current context to the most concrete implementation, that can be found.
</p>
-<p>It is important to know, that for a given offset in a model file, many possible grammar elements exist. The framework dispatches to the method declarations for any valid element. That means, that a bunch of '&#8216;complete.*&#8217;' may be called.</p>
+<p>It is important to know, that for a given offset in a model file, many possible grammar elements exist. The framework dispatches to the method declarations for any valid element. That means, that a bunch of '&lsquo;complete.*&rsquo;' may be called.</p>
</div>
<div class="section" title="Sample Implementation">
<div class="titlepage">
<div>
<div>
<h3 class="title">
-<a name="SampleImplementation"/>Sample Implementation</h3>
+<a name="SampleImplementation"></a>Sample Implementation</h3>
</div>
</div>
</div>
-<p>To provide a dummy proposal for the description of a model object, you may introduce a specialization of the generated method and implement it as follows. This will give &#8216;Description for model #7&#8217; for a model with the intAttribute '7'</p>
+<p>To provide a dummy proposal for the description of a model object, you may introduce a specialization of the generated method and implement it as follows. This will give &lsquo;Description for model #7&rsquo; for a model with the intAttribute '7'</p>
<div class="literallayout">
<p>
-<code class="code">public void completeModel_StringDescription (<br/>
-  Model model, <br/>
-  Assignment assignment, <br/>
-  ContentAssistContext context, <br/>
-  ICompletionProposalAcceptor acceptor) {<br/>
-  // call implementation in superclass<br/>
-  super.completeModel_StringDescription(<br/>
-    model, <br/>
-    assignment, <br/>
-    context, <br/>
-    acceptor);<br/>
-<br/>
-  // compute the plain proposal<br/>
-  String proposal = "Description for model #" + model.getIntAttribute();<br/>
-<br/>
-  // convert it to a valid STRING-terminal<br/>
-  proposal = getValueConverter().toString(proposal, "STRING");<br/>
-<br/>
-  // create the completion proposal<br/>
-  // the result may be null as the createCompletionProposal(..) methods <br/>
-  // check for valid prefixes<br/>
-  // and terminal token conflicts<br/>
-  ICompletionProposal completionProposal = <br/>
-    createCompletionProposal(proposal, contentAssistContext);<br/>
-<br/>
-  // register the proposal, the acceptor handles null-values gracefully<br/>
-  acceptor.accept(completionProposal);<br/>
-}<br/>
-<br/>
+<code class="code">public&nbsp;void&nbsp;completeModel_StringDescription&nbsp;(<br>
+&nbsp;&nbsp;Model&nbsp;model,&nbsp;<br>
+&nbsp;&nbsp;Assignment&nbsp;assignment,&nbsp;<br>
+&nbsp;&nbsp;ContentAssistContext&nbsp;context,&nbsp;<br>
+&nbsp;&nbsp;ICompletionProposalAcceptor&nbsp;acceptor)&nbsp;{<br>
+&nbsp;&nbsp;//&nbsp;call&nbsp;implementation&nbsp;in&nbsp;superclass<br>
+&nbsp;&nbsp;super.completeModel_StringDescription(<br>
+&nbsp;&nbsp;&nbsp;&nbsp;model,&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;assignment,&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;context,&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;acceptor);<br>
+
+<br>
+&nbsp;&nbsp;//&nbsp;compute&nbsp;the&nbsp;plain&nbsp;proposal<br>
+&nbsp;&nbsp;String&nbsp;proposal&nbsp;=&nbsp;"Description&nbsp;for&nbsp;model&nbsp;#"&nbsp;+&nbsp;model.getIntAttribute();<br>
+
+<br>
+&nbsp;&nbsp;//&nbsp;convert&nbsp;it&nbsp;to&nbsp;a&nbsp;valid&nbsp;STRING-terminal<br>
+&nbsp;&nbsp;proposal&nbsp;=&nbsp;getValueConverter().toString(proposal,&nbsp;"STRING");<br>
+
+<br>
+&nbsp;&nbsp;//&nbsp;create&nbsp;the&nbsp;completion&nbsp;proposal<br>
+&nbsp;&nbsp;//&nbsp;the&nbsp;result&nbsp;may&nbsp;be&nbsp;null&nbsp;as&nbsp;the&nbsp;createCompletionProposal(..)&nbsp;methods&nbsp;<br>
+&nbsp;&nbsp;//&nbsp;check&nbsp;for&nbsp;valid&nbsp;prefixes<br>
+&nbsp;&nbsp;//&nbsp;and&nbsp;terminal&nbsp;token&nbsp;conflicts<br>
+&nbsp;&nbsp;ICompletionProposal&nbsp;completionProposal&nbsp;=&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;createCompletionProposal(proposal,&nbsp;contentAssistContext);<br>
+
+<br>
+&nbsp;&nbsp;//&nbsp;register&nbsp;the&nbsp;proposal,&nbsp;the&nbsp;acceptor&nbsp;handles&nbsp;null-values&nbsp;gracefully<br>
+&nbsp;&nbsp;acceptor.accept(completionProposal);<br>
+}<br>
+
+<br>
+
</code>
</p>
</div>
View
35 plugins/org.eclipse.xtext.doc/help/dependencyInjection.html
@@ -1,25 +1,28 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Dependency Injection in Xtext with Google Guice</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="Overview.html" title="Overview"/>
-<link rel="prev" href="generator.html" title="The Generator"/>
-<link rel="next" href="RuntimeConcepts.html" title="Runtime Concepts"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="Overview.html" title="Overview">
+<link rel="prev" href="generator.html" title="The Generator">
+<link rel="next" href="RuntimeConcepts.html" title="Runtime Concepts">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Dependency Injection in Xtext with Google Guice</h1>
+<p>Xtext uses Google Guice in order to wire up and configure language infrstructures. This allows for very flexible customization of language infrastructure and at the same time
+ makes the different pieces far more testable. </p>
<div class="section" title="Modules">
<div class="titlepage">
<div>
<div>
<h3 class="title">
-<a name="Modules"/>Modules</h3>
+<a name="Modules"></a>Modules</h3>
</div>
</div>
</div>
-<p>The Guice Injector configuration is done through the use of Modules (also a Guice concept).
+<p>The Guice injector configuration is done through the use of modules (also a Guice concept).
The generator provides two modules when first called, one for runtime ([MyLanguage]RuntimeModule) and one for UI ([MyLanguage]UIModule).
These modules are initially empty and intended to be manually edited when needed. These are also the modules used directly by the setup methods.
By default these modules extend a fully generated module.</p>
@@ -28,7 +31,7 @@ <h3 class="title">
<div>
<div>
<h4 class="title">
-<a name="GeneratedModules"/>Generated Modules</h4>
+<a name="GeneratedModules"></a>Generated Modules</h4>
</div>
</div>
</div>
@@ -42,13 +45,12 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="DefaultModules"/>Default Modules</h4>
+<a name="DefaultModules"></a>Default Modules</h4>
</div>
</div>
</div>
<p>Finally the fully generated modules extend the
- <code class="code">DefaultRuntimeModule</code> (resp.
- <code class="code">DefaultUiModule</code>), which contains all the default configuration. The default configuration consists of all components for which we have generic default implementations (interpreting as opposed to generated).
+ <code class="code">DefaultRuntimeModule</code>, which contains all the default configuration. The default configuration consists of all components for which we have generic default implementations (interpreting as opposed to generated).
Examples are all the components used in linking, the outline view, hyperlinking and navigation.
</p>
</div>
@@ -57,7 +59,7 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="ChangingConfiguration"/>Changing Configuration</h4>
+<a name="ChangingConfiguration"></a>Changing Configuration</h4>
</div>
</div>
</div>
@@ -67,9 +69,10 @@ <h4 class="title">
This class allows to write bindings like so:</p>
<div class="literallayout">
<p>
-<code class="code">public Class&lt;? extends MyInterface&gt; bind[anyname]() {<br/>
-     return MyInterfaceImpl.class;<br/>
- }<br/>
+<code class="code">public&nbsp;Class&lt;?&nbsp;extends&nbsp;MyInterface&gt;&nbsp;bind[anyname]()&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;MyInterfaceImpl.class;<br>
+&nbsp;}<br>
+
</code>
</p>
</div>
View
158 plugins/org.eclipse.xtext.doc/help/differences.html
@@ -1,22 +1,23 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Differences</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF"/>
-<link rel="prev" href="Xtend_based_apis.html" title="Where are the Xtend-based APIs?"/>
-<link rel="next" href="NewFeatures.html" title="New Features"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="from_oaw_to_tmf.html" title="From oAW to TMF">
+<link rel="prev" href="Xtend_based_apis.html" title="Where are the Xtend-based APIs?">
+<link rel="next" href="NewFeatures.html" title="New Features">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Differences</h1>
-<p>In this section differences between oAW Xtext and TMF Xtext are outlined and explained. We&#8217;ll start from the APIs such as the grammar language and the validation and finish with the different hooks for customizing linking and several UI aspects, such as outline view and content assist. We&#8217;ll also try to map some of the oAW Xtext concepts to their counterparts in TMF Xtext.</p>
+<p>In this section differences between oAW Xtext and TMF Xtext are outlined and explained. We&rsquo;ll start from the APIs such as the grammar language and the validation and finish with the different hooks for customizing linking and several UI aspects, such as outline view and content assist. We&rsquo;ll also try to map some of the oAW Xtext concepts to their counterparts in TMF Xtext.</p>
<div class="section" title="Differences in the grammar language">
<div class="titlepage">
<div>
<div>
<h3 class="title">
-<a name="differenced_grammar_language"/>Differences in the grammar language</h3>
+<a name="differenced_grammar_language"></a>Differences in the grammar language</h3>
</div>
</div>
</div>
@@ -25,12 +26,14 @@ <h3 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  grammar my.namespace.Language with org.eclipse.xtext.common.Terminals<br/>
-  generate myDsl "http://www.namespace.my/2009/MyDSL"<br/>
- <br/>
-  FirstRule : ...<br/>
-<br/>
+<br>
+&nbsp;&nbsp;grammar&nbsp;my.namespace.Language&nbsp;with&nbsp;org.eclipse.xtext.common.Terminals<br>
+&nbsp;&nbsp;generate&nbsp;myDsl&nbsp;"http://www.namespace.my/2009/MyDSL"<br>
+&nbsp;<br>
+&nbsp;&nbsp;FirstRule&nbsp;:&nbsp;...<br>
+
+<br>
+
</code>
</p>
</div>
@@ -43,16 +46,17 @@ <h3 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_datatype_rules"/>String rules become Datatype rules</h4>
+<a name="differences_datatype_rules"></a>String rules become Datatype rules</h4>
</div>
</div>
</div>
-<p>The very handy String rules are still present in TMF Xtext but we generalized them so that you don&#8217;t need to write the &#8216;String&#8217; keyword in front of them and at the same time these rules can not only produce EStrings but (as the name suggests) any kind of EDatatype. Every parser rule that does neither include assignments nor calls any that does returns an EDataType containing the consumed data. Per default this is an EString but you can now simply create a parser rule returning other EDatatype as well (see TODO-REF).</p>
+<p>The very handy String rules are still present in TMF Xtext but we generalized them so that you don&rsquo;t need to write the &lsquo;String&rsquo; keyword in front of them and at the same time these rules can not only produce EStrings but (as the name suggests) any kind of EDatatype. Every parser rule that does neither include assignments nor calls any that does returns an EDataType containing the consumed data. Per default this is an EString but you can now simply create a parser rule returning other EDatatype as well (see TODO-REF).</p>
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  Float returns ecore::EDouble : INT ('.' INT)?;<br/>
+<br>
+&nbsp;&nbsp;Float&nbsp;returns&nbsp;ecore::EDouble&nbsp;:&nbsp;INT&nbsp;('.'&nbsp;INT)?;<br>
+
</code>
</p>
</div>
@@ -62,18 +66,19 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_enum_rules"/>Enum rules</h4>
+<a name="differences_enum_rules"></a>Enum rules</h4>
</div>
</div>
</div>
-<p>Enum rules have not changed significantly. The keyword has changed to be all lower case (&#8216;enum&#8217; instead of &#8216;Enum&#8217;).
+<p>Enum rules have not changed significantly. The keyword has changed to be all lower case (&lsquo;enum&rsquo; instead of &lsquo;Enum&rsquo;).
Also the right-hand side of the assignment is now optional. That is in oAW Xtext:</p>
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  Enum MyEnum : foo='foo' | bar='bar';<br/>
-  <br/>
+<br>
+&nbsp;&nbsp;Enum&nbsp;MyEnum&nbsp;:&nbsp;foo='foo'&nbsp;|&nbsp;bar='bar';<br>
+&nbsp;&nbsp;<br>
+
</code>
</p>
</div>
@@ -81,9 +86,10 @@ <h4 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  enum MyEnum : foo='foo' | bar='bar';<br/>
-   <br/>
+<br>
+&nbsp;&nbsp;enum&nbsp;MyEnum&nbsp;:&nbsp;foo='foo'&nbsp;|&nbsp;bar='bar';<br>
+&nbsp;&nbsp;&nbsp;<br>
+
</code>
</p>
</div>
@@ -91,9 +97,11 @@ <h4 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  enum MyEnum : foo | bar;<br/>
-<br/>
+<br>
+&nbsp;&nbsp;enum&nbsp;MyEnum&nbsp;:&nbsp;foo&nbsp;|&nbsp;bar;<br>
+
+<br>
+
</code>
</p>
</div>
@@ -103,7 +111,7 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_native_rules"/>Native rules</h4>
+<a name="differences_native_rules"></a>Native rules</h4>
</div>
</div>
</div>
@@ -113,8 +121,9 @@ <h4 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  Native FOO : "'f' 'o' 'o'";<br/>
+<br>
+&nbsp;&nbsp;Native&nbsp;FOO&nbsp;:&nbsp;"'f'&nbsp;'o'&nbsp;'o'";<br>
+
</code>
</p>
</div>
@@ -122,8 +131,9 @@ <h4 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  terminal FOO : 'f' 'o' 'o';<br/>
+<br>
+&nbsp;&nbsp;terminal&nbsp;FOO&nbsp;:&nbsp;'f'&nbsp;'o'&nbsp;'o';<br>
+
</code>
</p>
</div>
@@ -134,27 +144,29 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_no_URI_token"/>No URI terminal rule anymore</h4>
+<a name="differences_no_URI_token"></a>No URI terminal rule anymore</h4>
</div>
</div>
</div>
<p>We decided to remove the URI terminal. The only reason for the existence was to mark the model somehow so that the framework knows what information to use in order to load referenced models. Instead we decided to solve this similar to how we imply other defaults: by convention.</p>
-<p>So instead of using a special token which is syntactically a STRING token, the default import mechanism now looks for EAttributes of type EString with the name &#8216;importedURI&#8217;.
- That is if you&#8217;ve used the URI token like this:</p>
+<p>So instead of using a special token which is syntactically a STRING token, the default import mechanism now looks for EAttributes of type EString with the name &lsquo;importURI&rsquo;.
+ That is if you&rsquo;ve used the URI token like this:</p>
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  Import : 'import' myReference=URI;<br/>
+<br>
+&nbsp;&nbsp;Import&nbsp;:&nbsp;'import'&nbsp;myReference=URI;<br>
+
</code>
</p>
</div>
-<p>you&#8217;ll have to rewrite it that way</p>
+<p>you&rsquo;ll have to rewrite it that way</p>
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  Import : 'import' importedURI=STRING;<br/>
+<br>
+&nbsp;&nbsp;Import&nbsp;:&nbsp;'import'&nbsp;importURI=STRING;<br>
+
</code>
</p>
</div>
@@ -165,16 +177,17 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_return_types"/>Return types</h4>
+<a name="differences_return_types"></a>Return types</h4>
</div>
</div>
</div>
-<p>The syntax to explicitly declare the return type of a rule has changed. In oAW Xtext (where this was marked as &#8216;experimental&#8217;) the syntax was:</p>
+<p>The syntax to explicitly declare the return type of a rule has changed. In oAW Xtext (where this was marked as &lsquo;experimental&rsquo;) the syntax was:</p>
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  MyRule [MyType] : foo=ID;  <br/>
+<br>
+&nbsp;&nbsp;MyRule&nbsp;[MyType]&nbsp;:&nbsp;foo=ID;&nbsp;&nbsp;<br>
+
</code>
</p>
</div>
@@ -182,12 +195,13 @@ <h4 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  MyRule returns MyType : foo=ID;<br/>
+<br>
+&nbsp;&nbsp;MyRule&nbsp;returns&nbsp;MyType&nbsp;:&nbsp;foo=ID;<br>
+
</code>
</p>
</div>
-<p>This is a bit more verbose, but at the same time more readable. And as you don&#8217;t have to write the return type in most situations, it&#8217;s good to have a more explicit, readable syntax.</p>
+<p>This is a bit more verbose, but at the same time more readable. And as you don&rsquo;t have to write the return type in most situations, it&rsquo;s good to have a more explicit, readable syntax.</p>
</div>
</div>
<div class="section" title="Differences in Validation">
@@ -195,18 +209,19 @@ <h4 class="title">
<div>
<div>
<h3 class="title">
-<a name="differences_validation"/>Differences in Validation</h3>
+<a name="differences_validation"></a>Differences in Validation</h3>
</div>
</div>
</div>
-<p>TMF Xtext still supports implementing validation using Xpand&#8217;s Check. However it is no longer using the EMF meta model (typesystem) but now uses the so called JavaBeansMetamodel. This means that the types in Check and Xtend correspond to Java types. This requires minor changes (namely the namespaces to be imported are now the qualified name of the generated Java classes).
+<p>TMF Xtext still supports implementing validation using Xpand&rsquo;s Check. However it is no longer using the EMF meta model (typesystem) but now uses the so called JavaBeansMetamodel. This means that the types in Check and Xtend correspond to Java types. This requires minor changes (namely the namespaces to be imported are now the qualified name of the generated Java classes).
Example: If your Check file looked like this in oAW Xtext :</p>
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  import myMetamodel;<br/>
-  context Type ERROR "foo" : name!=null;   <br/>
+<br>
+&nbsp;&nbsp;import&nbsp;myMetamodel;<br>
+&nbsp;&nbsp;context&nbsp;Type&nbsp;ERROR&nbsp;"foo"&nbsp;:&nbsp;name!=null;&nbsp;&nbsp;&nbsp;<br>
+
</code>
</p>
</div>
@@ -214,14 +229,15 @@ <h3 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-  import my::pack::to::myMetaModel;<br/>
-  context Type ERROR "foo" : name!=null;<br/>
+<br>
+&nbsp;&nbsp;import&nbsp;my::pack::to::myMetaModel;<br>
+&nbsp;&nbsp;context&nbsp;Type&nbsp;ERROR&nbsp;"foo"&nbsp;:&nbsp;name!=null;<br>
+
</code>
</p>
</div>
<p>Where
- <code class="code">my::pack::to::myMetaModel</code> refers to the package the generated EClasses are in. In other words there&#8217;s a Java class
+ <code class="code">my::pack::to::myMetaModel</code> refers to the package the generated EClasses are in. In other words there&rsquo;s a Java class
<code class="code">my.pack.to.myMetaModel.Type</code>.
We changed this in order to allow use of any Java API from within Check and Xtend.
</p>
@@ -231,16 +247,16 @@ <h3 class="title">
<div>
<div>
<h3 class="title">
-<a name="differences_linking"/>Differences in Linking</h3>
+<a name="differences_linking"></a>Differences in Linking</h3>
</div>
</div>
</div>
-<p>The linking has been completely redesigned. In oAW Xtext linking was done in a very naive way: To find an element one queries a list of all &#8216;visible&#8217; EObjects, then filters out what is not needed and tries to find a match by comparing the text written for the crosslink with the value returned by the
+<p>The linking has been completely redesigned. In oAW Xtext linking was done in a very naive way: To find an element one queries a list of all &lsquo;visible&rsquo; EObjects, then filters out what is not needed and tries to find a match by comparing the text written for the crosslink with the value returned by the
<code class="code">id()</code> extension. As a side-effect of
<code class="code">link_feature()</code> the reference is set.
</p>
<p>The code about selecting and filtering
- <code class="code">allElements()</code> usually has been duplicated in the corresponding content assist function, so that linking and content assist are semantically in sync. If you&#8217;re good (we usually were not) you externalized that piece of code and reused the same extension in content assist and linking.
+ <code class="code">allElements()</code> usually has been duplicated in the corresponding content assist function, so that linking and content assist are semantically in sync. If you&rsquo;re good (we usually were not) you externalized that piece of code and reused the same extension in content assist and linking.
</p>
<p>To put it bluntly this approach could be summarized in two steps:</p>
<div class="orderedlist">
@@ -259,22 +275,22 @@ <h3 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_linking_sopes"/>The idea of scopes</h4>
+<a name="differences_linking_sopes"></a>The idea of scopes</h4>
</div>
</div>
</div>
-<p>In TMF Xtext we&#8217;ve introduced scopes and scope providers that are responsible for creating scopes. A scope is basically a set of name-&gt;value pairs. Scopes are implemented upon Iterables and are nested to build a hierarchy. With scopes we declare &#8220;visible&#8221; objects in a lazy and cost-saving way where the linker only navigates as far as necessary to find matching objects. The content assist reuses this set of visible objects to offer only reachable objects. </p>
+<p>In TMF Xtext we&rsquo;ve introduced scopes and scope providers that are responsible for creating scopes. A scope is basically a set of name-&gt;value pairs. Scopes are implemented upon Iterables and are nested to build a hierarchy. With scopes we declare &ldquo;visible&rdquo; objects in a lazy and cost-saving way where the linker only navigates as far as necessary to find matching objects. The content assist reuses this set of visible objects to offer only reachable objects. </p>
<p>When the linking has to be customized scoping is where most of the semantics typically goes into. By implementing an
- <a class="ulink" href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/plugins/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScopeProvider.java?root=Modeling_Project&amp;view=co" target="_new">IScopeProvider</a> for your language linking and content assist will automatically be kept in sync since both use the scope provider.
+ <a class="ulink" href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/plugins/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScopeProvider.java?root=Modeling_Project&view=co" target="_new">IScopeProvider</a> for your language linking and content assist will automatically be kept in sync since both use the scope provider.
</p>
<p>The provided default implementation is semantically mostly identical to how the default linking worked in oAW Xtext: </p>
<div class="orderedlist">
<ol class="orderedlist" type="1">
<li class="listitem">
-<p>Elements which have an attribute &#8216;name&#8217; will be made visible by their name</p>
+<p>Elements which have an attribute &lsquo;name&rsquo; will be made visible by their name</p>
</li>
<li class="listitem">
-<p>Referenced resources will be put on the (outer) scope by using the &#8216;importedURI&#8217;- naming convention (TODO-REF) and will only be loaded if necessary</p>
+<p>Referenced resources will be put on the (outer) scope by using the &lsquo;importURI&rsquo;- naming convention and will only be loaded if necessary</p>
</li>
<li class="listitem">
<p>The available elements are filtered by the expected type (i.e. the type of the reference to be linked)</p>
@@ -287,12 +303,12 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="differences_linking_migration"/>Migration</h4>
+<a name="differences_linking_migration"></a>Migration</h4>
</div>
</div>
</div>
-<p>We expect the migration of linking to be very simple if you&#8217;ve not changed the default semantics that much. We&#8217;ve already migrated a couple of projects and it wasn&#8217;t too hard to do so.
- If you have changed linking (and also content assist) a lot, you&#8217;ll have to translate the semantics to the IScopeProvider concept. This might be a bit of work, but it is worth the effort as this will clean up your code base and better separate concerns.</p>
+<p>We expect the migration of linking to be very simple if you&rsquo;ve not changed the default semantics that much. We&rsquo;ve already migrated a couple of projects and it wasn&rsquo;t too hard to do so.
+ If you have changed linking (and also content assist) a lot, you&rsquo;ll have to translate the semantics to the IScopeProvider concept. This might be a bit of work, but it is worth the effort as this will clean up your code base and better separate concerns.</p>
</div>
</div>
<div class="section" title="Differences in UI customizing">
@@ -300,12 +316,12 @@ <h4 class="title">
<div>
<div>
<h3 class="title">
-<a name="differences_ui"/>Differences in UI customizing</h3>
+<a name="differences_ui"></a>Differences in UI customizing</h3>
</div>
</div>
</div>
<p>In oAW Xtext several UI services such as content assist, outline view or the label provider have been customized using Xtend. In TMF Xtext there is no Xtend API for these aspects. Extensive model computations for the content assist is most probably not necessary anymore- it reuses scopes. And since we provide a declarative Java API that mimics the polymorphic dispatch and relies on static Ecore classes you will gain nearly the same expressiveness as before while increasing maintainability and performance.</p>
-<p>Beside the API change in favor of Java we have to mention that in TMF Xtext the outline view does not support multiple view points so far. This is just because we didn&#8217;t manage to get this included. We don&#8217;t think that view points are a bad idea in general, but we decided that other things were more important.</p>
+<p>Beside the API change in favor of Java we have to mention that in TMF Xtext the outline view does not support multiple view points so far. This is just because we didn&rsquo;t manage to get this included. We don&rsquo;t think that view points are a bad idea in general, but we decided that other things were more important.</p>
</div>
</body>
</html>
View
139 plugins/org.eclipse.xtext.doc/help/formatting.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Formatting (Pretty Printing)</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="IDEconcepts.html" title="IDE concepts"/>
-<link rel="prev" href="navigation.html" title="Navigation and Hyperlinking"/>
-<link rel="next" href="from_oaw_to_tmf.html" title="From oAW to TMF"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="IDEconcepts.html" title="IDE concepts">
+<link rel="prev" href="navigation.html" title="Navigation and Hyperlinking">
+<link rel="next" href="from_oaw_to_tmf.html" title="From oAW to TMF">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Formatting (Pretty Printing)</h1>
@@ -39,7 +40,7 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Formatting (Pretty P
<div>
<div>
<h3 class="title">
-<a name="declarativeformatter"/>Declarative Formatter </h3>
+<a name="declarativeformatter"></a>Declarative Formatter </h3>
</div>
</div>
</div>
@@ -49,34 +50,38 @@ <h3 class="title">
<div class="literallayout">
<p>
<code class="code">
-<br/>
-public class ExampleFormatter extends AbstractDeclarativeFormatter {<br/>
-<br/>
-  @Override<br/>
-  protected void configureFormatting(FormattingConfig c) {<br/>
-    ExampleLanguageGrammarAccess f = (ExampleLanguageGrammarAccess) getGrammarAccess();<br/>
-    <br/>
-    c.setAutoLinewrap(120);<br/>
-<br/>
-    // Line<br/>
-    c.setLinewrap(2).after(f.getLineAccess().getSemicolonKeyword_1());<br/>
-    c.setNoSpace().before(f.getLineAccess().getSemicolonKeyword_1());<br/>
-    <br/>
-    // TestIndentation<br/>
-    c.setIndentation(f.getTestIndentationAccess().getLeftCurlyBracketKeyword_1(),<br/>
-        f.getTestIndentationAccess().getRightCurlyBracketKeyword_3());<br/>
-    c.setLinewrap().after(f.getTestIndentationAccess().getLeftCurlyBracketKeyword_1());<br/>
-    c.setLinewrap().after(f.getTestIndentationAccess().getRightCurlyBracketKeyword_3());<br/>
-    <br/>
-    // Param<br/>
-    c.setNoLinewrap().around(f.getParamAccess().getColonKeyword_1());<br/>
-    c.setNoSpace().around(f.getParamAccess().getColonKeyword_1());<br/>
-    <br/>
-    // comments<br/>
-    c.setNoLinewrap().before(f.getSL_COMMENTRule());<br/>
-  }<br/>
-}<br/>
-<br/>
+<br>
+public&nbsp;class&nbsp;ExampleFormatter&nbsp;extends&nbsp;AbstractDeclarativeFormatter&nbsp;{<br>
+
+<br>
+&nbsp;&nbsp;@Override<br>
+&nbsp;&nbsp;protected&nbsp;void&nbsp;configureFormatting(FormattingConfig&nbsp;c)&nbsp;{<br>
+&nbsp;&nbsp;&nbsp;&nbsp;ExampleLanguageGrammarAccess&nbsp;f&nbsp;=&nbsp;(ExampleLanguageGrammarAccess)&nbsp;getGrammarAccess();<br>
+&nbsp;&nbsp;&nbsp;&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setAutoLinewrap(120);<br>
+
+<br>
+&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Line<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setLinewrap(2).after(f.getLineAccess().getSemicolonKeyword_1());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setNoSpace().before(f.getLineAccess().getSemicolonKeyword_1());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;TestIndentation<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setIndentation(f.getTestIndentationAccess().getLeftCurlyBracketKeyword_1(),<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;f.getTestIndentationAccess().getRightCurlyBracketKeyword_3());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setLinewrap().after(f.getTestIndentationAccess().getLeftCurlyBracketKeyword_1());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setLinewrap().after(f.getTestIndentationAccess().getRightCurlyBracketKeyword_3());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Param<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setNoLinewrap().around(f.getParamAccess().getColonKeyword_1());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setNoSpace().around(f.getParamAccess().getColonKeyword_1());<br>
+&nbsp;&nbsp;&nbsp;&nbsp;<br>
+&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;comments<br>
+&nbsp;&nbsp;&nbsp;&nbsp;c.setNoLinewrap().before(f.getSL_COMMENTRule());<br>
+&nbsp;&nbsp;}<br>
+}<br>
+
+<br>
+
</code>
</p>
</div>
@@ -92,7 +97,7 @@ <h3 class="title">
<div>
<div>
<h4 class="title">
-<a name="GeneralFormattingConfigSettings"/>General FormattingConfig Settings</h4>
+<a name="GeneralFormattingConfigSettings"></a>General FormattingConfig Settings</h4>
</div>
</div>
</div>
@@ -100,24 +105,28 @@ <h4 class="title">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>
- <code class="code">setAutoLinewrap(int)</code> defines the amount of characters after which a linebreak should be dynamically inserted between two tokens. The rule
+
+<code class="code">setAutoLinewrap(int)</code> defines the amount of characters after which a linebreak should be dynamically inserted between two tokens. The rule
<code class="code">setNoLinewrap()</code> can be used to suppress this behavior locally. The default is 80.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">setIndentationSpace(String)</code> defines the string which is used for a single degree of indentation. The default is two whitespaces.
+
+<code class="code">setIndentationSpace(String)</code> defines the string which is used for a single degree of indentation. The default is two whitespaces.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">setWhitespaceRule(AbstractRule)</code> defines the grammar rule which is used to match whitespaces. This is needed by the formatter to identify whitespaces and to insert whitespaces. The default is the rule named
+
+<code class="code">setWhitespaceRule(AbstractRule)</code> defines the grammar rule which is used to match whitespaces. This is needed by the formatter to identify whitespaces and to insert whitespaces. The default is the rule named
<code class="code">WS</code>.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">setIndentation(startele, endele)</code> increases the level of indentation when
+
+<code class="code">setIndentation(startele, endele)</code> increases the level of indentation when
<code class="code">startele</code> is matched and decreases the level when
<code class="code">endele</code> is matched. The matching of elements happens in the same way as it does for formatting rules.
</p>
@@ -130,61 +139,61 @@ <h4 class="title">
<div>
<div>
<h4 class="title">
-<a name="FormattingConfigRules"/>FormattingConfig Rules</h4>
+<a name="FormattingConfigRules"></a>FormattingConfig Rules</h4>
</div>
</div>
</div>
<p>Per default, the
<a class="link" href="formatting.html#declarativeformatter" title="Declarative Formatter">Declarative Formatter</a> inserts one whitespace between two tokens. Rules can be used to specify a different behavior. They consist of two parts:
- <span class="emphasis">
-<em>When</em>
-</span> to apply the rule and
- <span class="emphasis">
-<em>what</em>
-</span> to do.
+ <span class="emphasis"><em>When</em></span> to apply the rule and
+ <span class="emphasis"><em>what</em></span> to do.
</p>
<p>To understand
- <span class="emphasis">
-<em>when</em>
-</span> a rule is applied think of a stream of tokens whereas each token is associated with the corresponding grammar element. The rules are matched against these grammar elements. The following matching constructs exist.
+ <span class="emphasis"><em>when</em></span> a rule is applied think of a stream of tokens whereas each token is associated with the corresponding grammar element. The rules are matched against these grammar elements. The following matching constructs exist.
</p>
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>
- <code class="code">after(ele)</code>: The rule is executed after the grammar element
- <code class="code">ele</code> has been matched. For example, if your grammar uses the keyword &#8220;;&#8221; to end lines, this can instruct the formatter to insert a linebreak after the semicolon.
+
+<code class="code">after(ele)</code>: The rule is executed after the grammar element
+ <code class="code">ele</code> has been matched. For example, if your grammar uses the keyword &ldquo;;&rdquo; to end lines, this can instruct the formatter to insert a linebreak after the semicolon.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">before(ele)</code>: The rule is executed before the matched element. For example, if your grammar contains lists which separate its values with keyword &#8220;,&#8221;, you this can instruct the formatter to suppress the whitespace before the comma.
+
+<code class="code">before(ele)</code>: The rule is executed before the matched element. For example, if your grammar contains lists which separate its values with keyword &ldquo;,&rdquo;, you this can instruct the formatter to suppress the whitespace before the comma.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">around(ele)</code>: This is the same as
+
+<code class="code">around(ele)</code>: This is the same as
<code class="code">before(ele)</code> combined with
<code class="code">after(ele)</code>.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">between(ele1, ele2)</code>: This matches if
+
+<code class="code">between(ele1, ele2)</code>: This matches if
<code class="code">ele2</code> directly follows
<code class="code">ele1</code>. There may be no other elements in between.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">bounds(ele1, ele2)</code>: This is the same as
+
+<code class="code">bounds(ele1, ele2)</code>: This is the same as
<code class="code">before(ele1)</code> combined with
<code class="code">after(ele2)</code>.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">range(ele1, ele2)</code>: The rule is enabled when
+
+<code class="code">range(ele1, ele2)</code>: The rule is enabled when
<code class="code">ele1</code> is matched, and disabled when
<code class="code">ele2</code> is matched. Thereby, the rule is active for the complete region which is surrounded by
<code class="code">ele1</code> and
@@ -194,8 +203,8 @@ <h4 class="title">
</ul>
</div>
<p>The parameter
- <code class="code">ele</code> can be a grammar&#8217;s
- <code class="code">AbstractElement</code> or a grammar&#8217;s
+ <code class="code">ele</code> can be a grammar&rsquo;s
+ <code class="code">AbstractElement</code> or a grammar&rsquo;s
<code class="code">AbstractRule</code>. However, only elements which represent one token in the textual representation can be matched. This are:
</p>
<div class="itemizedlist">
@@ -213,22 +222,26 @@ <h4 class="title">
<ul class="itemizedlist" type="disc">
<li class="listitem">
<p>
- <code class="code">setLinewrap()</code>: Inserts a linebreak at this position.
+
+<code class="code">setLinewrap()</code>: Inserts a linebreak at this position.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">setLinewrap(int)</code>: Inserts the specified number of linebreak at this position.
+
+<code class="code">setLinewrap(int)</code>: Inserts the specified number of linebreak at this position.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">setNoLinewrap()</code>: Suppresses automatic line wrap, which may occur when the line&#8217;s length exceeds the defined limit.
+
+<code class="code">setNoLinewrap()</code>: Suppresses automatic line wrap, which may occur when the line&rsquo;s length exceeds the defined limit.
</p>
</li>
<li class="listitem">
<p>
- <code class="code">setNoSpace()</code>: Suppresses the whitespace between tokens at this position. Be aware that between some tokens a whitespace is required to maintain a valid concrete syntax.
+
+<code class="code">setNoSpace()</code>: Suppresses the whitespace between tokens at this position. Be aware that between some tokens a whitespace is required to maintain a valid concrete syntax.
</p>
</li>
</ul>
View
65 plugins/org.eclipse.xtext.doc/help/fragmentProvider.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Fragment Provider (referencing Xtext models from other EMF artifacts)</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="RuntimeConcepts.html" title="Runtime Concepts"/>
-<link rel="prev" href="serialization.html" title="Serialization"/>
-<link rel="next" href="IDEconcepts.html" title="IDE concepts"/>
+<link href="book.css" rel="stylesheet" type="text/css">
+<meta content="DocBook XSL Stylesheets V1.75.1" name="generator">
+<link rel="home" href="index.html" title="Xtext User Guide">
+<link rel="up" href="RuntimeConcepts.html" title="Runtime Concepts">
+<link rel="prev" href="serialization.html" title="Serialization">
+<link rel="next" href="IDEconcepts.html" title="IDE concepts">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Fragment Provider (referencing Xtext models from other EMF artifacts)</h1>
@@ -14,13 +15,11 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Fragment Provider (r
<code class="code">EObject</code> from non-Xtext models.
In those cases URIs are used, which are made up of a part identifying the resource. Each
<code class="code">EObject</code> contained in a resource can be identified by a so called
- <span class="emphasis">
-<em>fragment</em>
-</span>.
+ <span class="emphasis"><em>fragment</em></span>.
</p>
<p>A fragment is a part of an EMF URI and needs to be unique per resource.</p>
<p>The generic XMI resource shipped with EMF provides a generic path-like computation of fragments. With an XMI or other binary-like serialization it is also common and possible to use UUIDs.</p>
-<p>However with a textual concrete syntax we want to be able to compute fragments out of the given information. We don&#8217;t want to force people to use UUIDs (i.e. synthetic identifiers) or relative generic paths (very fragile), in order to refer to
+<p>However with a textual concrete syntax we want to be able to compute fragments out of the given information. We don&rsquo;t want to force people to use UUIDs (i.e. synthetic identifiers) or relative generic paths (very fragile), in order to refer to
<code class="code">EObjects</code>.
</p>
<p>Therefore one can contribute a so called
@@ -28,30 +27,32 @@ <h1 xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">Fragment Provider (r
</p>
<div class="literallayout">
<p>
-<code class="code">public interface IFragmentProvider extends ILanguageService {<br/>
- <br/>
-  /**<br/>
-   * Computes the local ID of the given object. <br/>
-   * @param obj<br/>
-   *            The EObject to compute the fragment for<br/>
-   * @return the fragment, which can be an arbitrary string but must be <br/>
-   *         unique within a resource. Return null to use default <br/>
-   *         implementation<br/>
-   */<br/>
-  String getFragment(EObject obj);<br/>
-  <br/>
-  /**<br/>
-   * Locates an EObject in a resource by its fragment. <br/>
-   * @param resource<br/>
-   * @param fragment<br/>
-   * @return the EObject <br/>
-   */<br/>
-  EObject getEObject(Resource resource, String fragment);<br/>
- }<br/>
-<br/>
+<code class="code">public&nbsp;interface&nbsp;IFragmentProvider&nbsp;extends&nbsp;ILanguageService&nbsp;{<br>
+&nbsp;<br>
+&nbsp;&nbsp;/**<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;Computes&nbsp;the&nbsp;local&nbsp;ID&nbsp;of&nbsp;the&nbsp;given&nbsp;object.&nbsp;<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;@param&nbsp;obj<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;EObject&nbsp;to&nbsp;compute&nbsp;the&nbsp;fragment&nbsp;for<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;@return&nbsp;the&nbsp;fragment,&nbsp;which&nbsp;can&nbsp;be&nbsp;an&nbsp;arbitrary&nbsp;string&nbsp;but&nbsp;must&nbsp;be&nbsp;<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unique&nbsp;within&nbsp;a&nbsp;resource.&nbsp;Return&nbsp;null&nbsp;to&nbsp;use&nbsp;default&nbsp;<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implementation<br>
+&nbsp;&nbsp;&nbsp;*/<br>
+&nbsp;&nbsp;String&nbsp;getFragment(EObject&nbsp;obj);<br>
+&nbsp;&nbsp;<br>
+&nbsp;&nbsp;/**<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;Locates&nbsp;an&nbsp;EObject&nbsp;in&nbsp;a&nbsp;resource&nbsp;by&nbsp;its&nbsp;fragment.&nbsp;<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;@param&nbsp;resource<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;@param&nbsp;fragment<br>
+&nbsp;&nbsp;&nbsp;*&nbsp;@return&nbsp;the&nbsp;EObject&nbsp;<br>
+&nbsp;&nbsp;&nbsp;*/<br>
+&nbsp;&nbsp;EObject&nbsp;getEObject(Resource&nbsp;resource,&nbsp;String&nbsp;fragment);<br>
+&nbsp;}<br>
+
+<br>
+
</code>
</p>
</div>
-<p>However, the currently available default fragment provider does nothing.</p>
+<p>Note that the currently available default fragment provider does nothing (i.e. refers to the default behavior of EMF).</p>
</body>
</html>
View
15 plugins/org.eclipse.xtext.doc/help/from_oaw_to_tmf.html
@@ -1,12 +1,13 @@
<html>
<head>
+<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>From oAW to TMF</title>
-<link href="book.css" rel="stylesheet" type="text/css"/>
-<meta content="DocBook XSL Stylesheets V1.75.1" name="generator"/>
-<link rel="home" href="index.html" title="Xtext User Guide"/>
-<link rel="up" href="index.html" title="Xtext User Guide"/>
-<link rel="prev" href="formatting.html" title="Formatting (Pretty Printing)"/>
-<link rel="next" href="migration_overview.html"