| <html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Xpand Documentation</title><link href="book.css" rel="stylesheet" type="text/css"><meta content="DocBook XSL Stylesheets V1.75.1" name="generator"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="Xpand Documentation"><div class="titlepage"><div><div><h1 class="title"><a name="xpand_documentation"></a>Xpand Documentation</h1></div></div><hr></div><div class="chapter" title="Chapter 1. Getting Started"><div class="titlepage"><div><div><h2 class="title"><a name="emf_tutorial"></a>Chapter 1. Getting Started</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#emf_tutorial_installing">Xpand Setup</a></span></dt><dt><span class="section"><a href="#emf_tutorial_overview">Tutorial overview</a></span></dt><dt><span class="section"><a href="#emf_tutorial_define_metamodel">Defining an EMF metamodel</a></span></dt><dd><dl><dt><span class="section"><a href="#emf_tutorial_creating_emf_project">Creating an EMF project</a></span></dt><dt><span class="section"><a href="#emf_tutorial_defining_metamodel">Defining the (meta)model</a></span></dt></dl></dd><dt><span class="section"><a href="#emf_tutorial_generate_emf_tooling">Generating the EMF tooling</a></span></dt><dt><span class="section"><a href="#emf_tutorial_setting_generator_project">Setting up the generator project</a></span></dt><dt><span class="section"><a href="#emf_tutorial_defining_sample_model">Defining an Example Data Model</a></span></dt><dt><span class="section"><a href="#emf_tutorial_dynamic_emf">Using Dynamic EMF</a></span></dt><dt><span class="section"><a href="#emf_tutorial_generating_code">Generating code from the example model</a></span></dt><dd><dl><dt><span class="section"><a href="#emf_tutorial_the_workflow_definition">The workflow definition</a></span></dt><dt><span class="section"><a href="#emf_tutorial_running_the_workflow">Running the workflow</a></span></dt><dt><span class="section"><a href="#emf_tutorial_templates">Templates</a></span></dt><dt><span class="section"><a href="#emf_tutorial_running_the_generator_again">Running the generator again</a></span></dt></dl></dd><dt><span class="section"><a href="#emf_tutorial_checking_contraints_with_check">Checking Constraints with the <span class="emphasis"><em>Check</em></span> |
| Language</a></span></dt><dd><dl><dt><span class="section"><a href="#emf_tutorial_defining_the_constraint">Defining the constraint</a></span></dt><dt><span class="section"><a href="#emf_tutorial_integration_into_the_workflow_file">Integration into the workflow file</a></span></dt></dl></dd><dt><span class="section"><a href="#emf_tutorial_extensions">Extensions</a></span></dt><dd><dl><dt><span class="section"><a href="#emf_tutorial_expression_extensions">Expression Extensions</a></span></dt><dt><span class="section"><a href="#emf_tutorial_java_extensions">Java Extensions</a></span></dt></dl></dd></dl></div><p>This example uses Eclipse EMF<a name="N1000D" class="indexterm"></a> as the basis for code generation. A large amount of available |
| third-party tools makes EMF a good basis. Specifically, better tools for |
| building EMF metamodels are available already (Xtext, GMF, etc.). To get a |
| deeper understanding of EMF we recommend that you first read the EMF |
| tutorial at </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www-128.ibm.com/developerworks/library/os-ecemf1/" target="_new">http://www-128.ibm.com/developerworks/library/os-ecemf1/</a></p></li><li class="listitem"><p><a class="ulink" href="http://www-128.ibm.com/developerworks/library/os-ecemf2/" target="_new">http://www-128.ibm.com/developerworks/library/os-ecemf2/</a></p></li><li class="listitem"><p><a class="ulink" href="http://www-128.ibm.com/developerworks/library/os-ecemf3/" target="_new">http://www-128.ibm.com/developerworks/library/os-ecemf3/</a></p></li></ul></div><p> You can also run this tutorial without a complete |
| understanding of EMF, but the tutorial might seem unnecessarily complex to |
| you.</p><div class="section" title="Xpand Setup"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_installing"></a>Xpand Setup</h2></div></div></div><p>Before you can go through the tutorial and execute the examples, you |
| need to have Xpand installed. Please consider <a class="ulink" href="http://www.eclipse.org/modeling/m2t/downloads/?project=xpand" target="_new">http://www.eclipse.org/modeling/m2t/downloads/?project=xpand</a> |
| for details.</p></div><div class="section" title="Tutorial overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_overview"></a>Tutorial overview</h2></div></div></div><p>The purpose of this tutorial is to illustrate code generation with |
| Xpand from EMF models. The process we are going to go through, will start |
| by defining a metamodel (using EMF tooling), coming up with some example |
| data, writing code generation templates, running the generator and finally |
| adding some constraint checks.</p><p>The actual content of the example is rather trivial – we will |
| generate Java classes following the JavaBean conventions. The model will |
| contain entities (such as <span class="type">Person</span> or <span class="type">Vehicle</span>) |
| including some attributes and relationships among them – a rather typical |
| data model. From these entities in the model, we want to generate the |
| Beans for implementation in Java. In a real setting, we might also want to |
| generate persistence mappings, etc. We will not do this for this simple |
| introduction.</p></div><div class="section" title="Defining an EMF metamodel"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_define_metamodel"></a>Defining an EMF metamodel</h2></div></div></div><p>To illustrate the metamodel, before we deal with the intricacies of |
| EMF, here is the metamodel in UML: </p><div class="figure"><a name="emf_tutorial_sample_metamodel"></a><p class="title"><b>Figure 1. Sample metamodel</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/metamodel.gif" alt="Sample metamodel"></div></div></div><p><br class="figure-break"></p><div class="section" title="Creating an EMF project"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_creating_emf_project"></a>Creating an EMF project</h3></div></div></div><p>Create an EMF project as depicted below:</p><div class="figure"><a name="emf_tutorial_create_emf_project"></a><p class="title"><b>Figure 2. Create EMF project</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_emf_project.png" alt="Create EMF project"></div></div></div><br class="figure-break"><p>It is important that you create an EMF projec<a name="N10060" class="indexterm"></a>t, not just a simple or a Java project. Name it |
| <code class="filename">xpand.demo.emf.datamodel</code>.</p></div><div class="section" title="Defining the (meta)model"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_defining_metamodel"></a>Defining the (meta)model</h3></div></div></div><p>Create a new source folder <code class="filename">metamodel</code> in that project. Then, create a |
| new Ecore model in that source folder named |
| <code class="filename">data.ecore</code>. Use <span class="type">EPackage</span> as the model |
| object. </p><div class="figure"><a name="emf_tutorial_create_ecore_model"></a><p class="title"><b>Figure 3. Create new Ecore model</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_model.png" alt="Create new Ecore model"></div></div></div><p><br class="figure-break">This opens the Ecore Editor. You will see a root package with |
| name <code class="varname">null</code>. Open the Properties View (context menu). |
| Set the following properties for the package: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Name: data</p></li><li class="listitem"><p>Ns prefix: data</p></li><li class="listitem"><p>Ns URI: http://www.xpand.org/xpand.demo.emf.datamodel</p></li></ul></div><p> </p><div class="figure"><a name="emf_tutorial_adjust_namespace_settings"></a><p class="title"><b>Figure 4. Adjust namespace settings</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_model_adjust_namespace.png" alt="Adjust namespace settings"></div></div></div><p><br class="figure-break"></p><p>Create the following Ecore model.<sup>[<a href="#ftn.N100A4" name="N100A4" class="footnote">1</a>]</sup>Make sure you set the following properties |
| <span class="emphasis"><em>exactly</em></span> as described next:</p><p>Within the <span class="package">data</span> package, create these |
| <code class="classname">EClass</code> elements with their attributes:<sup>[<a href="#ftn.N100B6" name="N100B6" class="footnote">2</a>]</sup></p><div class="informaltable"><a name="emf_tutorial_metamodel_attributes"></a><table border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">EClass name</th><th align="left">EAttribute name</th><th align="left">EAttribute EType</th></tr></thead><tbody><tr><td align="left">DataModel</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">name</td><td align="left">EString</td></tr><tr><td align="left">Entity</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">name</td><td align="left">EString</td></tr><tr><td align="left">Attribute</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">name</td><td align="left">EString</td></tr><tr><td align="left"> </td><td align="left">type</td><td align="left">EString</td></tr><tr><td align="left">EntityReference</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">name</td><td align="left">EString</td></tr><tr><td align="left"> </td><td align="left">toMany</td><td align="left">EBoolean</td></tr></tbody></table></div><p>Now, it is time to create references between the model elements. |
| Add children of type <code class="classname">EReferences</code> as |
| follows:<sup>[<a href="#ftn.N1010E" name="N1010E" class="footnote">3</a>]</sup></p><div class="informaltable"><a name="emf_tutorial_metamodel_references"></a><table width="100%" border="1"><colgroup><col align="left"><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">EClass</th><th align="left">EReference name</th><th align="left">EReference attribute name</th><th align="left">EReference attribute value</th></tr></thead><tbody><tr><td align="left">DataModel</td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">entity</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">EType</td><td align="left">Entity</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">containment</td><td align="left">true</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Lowerbound</td><td align="left">0</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Upperbound</td><td align="left">-1</td></tr><tr><td align="left">Entity</td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">attribute</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">EType</td><td align="left">Attribute</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">containment</td><td align="left">true</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Lowerbound</td><td align="left">1</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Upperbound</td><td align="left">-1</td></tr><tr><td align="left">Entity</td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">reference</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">EType</td><td align="left">EntityReference</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">containment</td><td align="left">true</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Lowerbound</td><td align="left">0</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Upperbound</td><td align="left">-1</td></tr><tr><td align="left">EntityReference</td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left">target</td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">EType</td><td align="left">Entity</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">containment</td><td align="left">false</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Lowerbound</td><td align="left">1</td></tr><tr><td align="left"> </td><td align="left"> </td><td align="left">Upperbound</td><td align="left">1</td></tr></tbody></table></div><div class="figure"><a name="emf_tutorial_metamodel_structure"></a><p class="title"><b>Figure 5. Metamodel structure</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_model_mm_structure.png" alt="Metamodel structure"></div></div></div><p><br class="figure-break"></p><p>EMF saves the model we created above in its own dialect of |
| XMI<a name="N101D9" class="indexterm"></a>. To avoid any ambiguities, here is the complete XMI |
| source for the metamodel. It goes into the file |
| <code class="filename">data.ecore</code>: </p><pre class="programlisting"><?xml version="1.0" encoding="UTF-8"?> |
| <ecore:EPackage xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
| xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="data" |
| nsURI="http://www.xpand.org/xpand.demo.emf.datamodel" nsPrefix="data"> |
| <eClassifiers xsi:type="ecore:EClass" name="DataModel"> |
| <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" |
| eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> |
| <eStructuralFeatures xsi:type="ecore:EReference" name="entity" upperBound="-1" |
| eType="#//Entity" containment="true"/> |
| </eClassifiers> |
| <eClassifiers xsi:type="ecore:EClass" name="Entity"> |
| <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" |
| eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> |
| <eStructuralFeatures xsi:type="ecore:EReference" name="attribute" lowerBound="1" |
| upperBound="-1" eType="#//Attribute" containment="true"/> |
| <eStructuralFeatures xsi:type="ecore:EReference" name="reference" upperBound="-1" |
| eType="#//EntityReference" containment="true"/> |
| </eClassifiers> |
| <eClassifiers xsi:type="ecore:EClass" name="Attribute"> |
| <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" |
| eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> |
| <eStructuralFeatures xsi:type="ecore:EAttribute" name="type" |
| eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> |
| </eClassifiers> |
| <eClassifiers xsi:type="ecore:EClass" name="EntityReference"> |
| <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" |
| eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> |
| <eStructuralFeatures xsi:type="ecore:EAttribute" name="toMany" |
| eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/> |
| <eStructuralFeatures xsi:type="ecore:EReference" name="target" lowerBound="1" |
| eType="#//Entity"/> |
| </eClassifiers> |
| </ecore:EPackage> |
| </pre></div></div><div class="section" title="Generating the EMF tooling"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_generate_emf_tooling"></a>Generating the EMF tooling</h2></div></div></div><p>In addition to providing the Ecore meta-metamodel<a name="N101E8" class="indexterm"></a>, EMF also comes with support for building (more or less |
| usable) editors. These are generated automatically from the metamodel we |
| just defined. In order to define example models (which we will do below) |
| we have to generate these editors. Also, we have to generate the |
| implementation classes for our metamodel. To generate all these things, we |
| have to define a markup model that contains a number of specifics to |
| control the generation of the various artifacts. This markup model is |
| called <span class="emphasis"><em>genmodel</em></span><a name="N101EE" class="indexterm"></a>.</p><p>So we have to define the <span class="emphasis"><em>genmodel</em></span> first. Select |
| the <code class="filename">data.ecore</code> model in the explorer and right mouse |
| click to <span class="guimenu">New</span> → <span class="guisubmenu">Other</span> → <span class="guisubmenu">Eclipse Modelling Framework</span> → <span class="guimenuitem">EMF Generator Model</span>. Follow the following five steps; note that they are also |
| illustrated in the next figure. </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Select EMF Generator Model</p></li><li class="listitem"><p>Define the name</p></li><li class="listitem"><p>Select the folder</p></li><li class="listitem"><p>Select Ecore model as source</p></li><li class="listitem"><p>Press the <span class="emphasis"><em>Load</em></span> button and then |
| <span class="emphasis"><em>Finish</em></span></p></li></ol></div><p> </p><div class="figure"><a name="emf_tutorial_creating_genmodel"></a><p class="title"><b>Figure 6. Creating the genmodel</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_genmodel_step_all_admonitions.png" alt="Creating the genmodel"></div></div></div><p><br class="figure-break"></p><p>As a consequence, you will get the finished EMF |
| <span class="emphasis"><em>genmodel</em></span>. It is a kind of "wrapper" around the |
| original metamodel, thus, it has the same structure, but the model |
| elements have different properties. As of now, you do not have to change |
| any of these. </p><div class="figure"><a name="emf_tutorial_structure_genmodel"></a><p class="title"><b>Figure 7. Structure of the genmodel</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_genmodel_gm_structure.png" alt="Structure of the genmodel"></div></div></div><p><br class="figure-break"></p><p>You can now generate the other projects. </p><div class="figure"><a name="emf_tutorial_creating_editing_projects"></a><p class="title"><b>Figure 8. Generate editing projects</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_genmodel_generate_all.png" alt="Generate editing projects"></div></div></div><p><br class="figure-break"></p><p>You now have all the generated additional projects. </p><div class="figure"><a name="emf_tutorial_generated_projects"></a><p class="title"><b>Figure 9. Generated projects</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_ecore_genmodel_generated_projects.png" alt="Generated projects"></div></div></div><p><br class="figure-break"></p><p>We will not look any deeper at these additional projects for now. |
| However, there is one important thing to point out: The generator also |
| generated the implementation classes for the metamodel. If you take a look |
| into <code class="filename">xpand.demo.emf.datamodel/src</code> |
| folder, you can find classes (actually, interfaces at the top level) that |
| represent the concepts defined in your metamodel. These can be used to |
| access the model. For some more details on how to use the EMF model APIs |
| as well as the reflective cousins, take a look at <a class="ulink" href="http://voelterblog.blogspot.com/2005/12/codeblogck-emf_10.html" target="_new">http://voelterblog.blogspot.com/2005/12/codeblogck-emf_10.html</a>.</p></div><div class="section" title="Setting up the generator project"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_setting_generator_project"></a>Setting up the generator project</h2></div></div></div><p>In order to make it a bit less painless to work with Eclipse EMF (we |
| would have to export the plugins, restart Eclipse, etc. etc.), we start |
| another Eclipse in the IDE. This instance is called the <span class="emphasis"><em>Runtime |
| Workbench</em></span>. Therefore select the |
| <code class="filename">xpand.demo.emf.datamodel.edit</code> project and choose from |
| the context menu <span class="guimenu">Run As</span> → <span class="guimenuitem">Eclipse Application</span>. </p><div class="figure"><a name="emf_tutorial_launch_runtime_platform"></a><p class="title"><b>Figure 10. Launch runtime platform</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/runas_eclipseapplication.png" width="324" alt="Launch runtime platform"></div></div></div><p><br class="figure-break"></p><p>If you are using a Mac or *nix you should now open the workspace |
| preference page and change the default encoding<a name="N10287" class="indexterm"></a> to ISO-8859-1.<sup>[<a href="#ftn.N1028B" name="N1028B" class="footnote">4</a>]</sup>Import the <code class="filename">xpand.demo.emf.datamodel</code> |
| project from your original workspace.<sup>[<a href="#ftn.N102A0" name="N102A0" class="footnote">5</a>]</sup> Note that importing the project does not physically move the |
| files,<sup>[<a href="#ftn.N102AC" name="N102AC" class="footnote">6</a>]</sup> so you can have the project be part of both workspaces at |
| the same time.</p><p>Create a new Xpand Project<sup>[<a href="#ftn.N102B2" name="N102B2" class="footnote">7</a>]</sup> called <code class="filename">xpand.demo.emf.datamodel.generator</code>. Do not |
| choose the option "Generate a simple example". </p><div class="figure"><a name="emf_tutorial_create_new_xpand_project"></a><p class="title"><b>Figure 11. Create new Xpand project</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_new_xpand_project.png" alt="Create new Xpand project"></div></div></div><p><br class="figure-break"></p><p>Your Xpand project will already be configured for use of EMF models. |
| You can check this in the project properties dialog: </p><div class="figure"><a name="emf_tutorial_project_properties"></a><p class="title"><b>Figure 12. Project properties</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_new_xpand_project_step2.png" alt="Project properties"></div></div></div><p><br class="figure-break"></p></div><div class="section" title="Defining an Example Data Model"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_defining_sample_model"></a>Defining an Example Data Model</h2></div></div></div><p>Select the <code class="filename">src</code> folder and |
| then choose <span class="guimenu">New</span> → <span class="guisubmenu">Other</span> → <span class="guisubmenu">Example EMF Model Creation Wizards</span> → <span class="guimenuitem">Data Model</span>. Create a new data model, call it |
| <code class="filename">example.data</code>. On the last page of the wizard, select |
| <span class="emphasis"><em>Model</em></span> as model object. </p><div class="figure"><a name="emf_tutorial_create_sample_data_model"></a><p class="title"><b>Figure 13. Create a sample data model</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/create_data_model.png" alt="Create a sample data model"></div></div></div><p><br class="figure-break"></p><p>Next, populate this very model as following. Please note that in the |
| case of attributes you have to define a type as well (i.e. String), not |
| just a name. </p><div class="figure"><a name="emf_tutorial_sample_data_model"></a><p class="title"><b>Figure 14. Sample data model</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/sample_datamodel.png" alt="Sample data model"></div></div></div><p><br class="figure-break"></p><p>Again, to avoid any typos here is the XMI for |
| <code class="filename">example.data</code>:</p><pre class="programlisting"><?xml version="1.0" encoding="UTF-8"?> |
| <data:DataModel |
| xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" |
| xmlns:data="http://www.xpand.org/xpand.demo.emf.datamodel"> |
| <entity name="Person"> |
| <attribute name="name" type="String"/> |
| <reference name="cars" toMany="true" target="//@entity.1"/> |
| </entity> |
| <entity name="Vehicle"> |
| <attribute name="plate" type="String"/> |
| </entity> |
| </data:DataModel> |
| </pre></div><div class="section" title="Using Dynamic EMF"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_dynamic_emf"></a>Using Dynamic EMF</h2></div></div></div><p>Instead of generating editors and metaclasses, you can also use |
| dynamic EMF<a name="N10328" class="indexterm"></a>. This works by selecting, in the opened metamodel, the root |
| class of the model you want to create (here: |
| <span class="emphasis"><em>DataModel</em></span>) and then selecting <span class="guimenuitem">Create Dynamic Instance</span> from the context menu. This opens an editor that can |
| dynamically edit the respective instance. The created file by default has |
| an <code class="filename">.xmi</code> extension.</p><p>Note that Xpand can work completely with dynamic models, there is no |
| reason to generate code. However, if you want to programmatically work |
| with the model, the generated metaclasses (not the editors!) are really |
| helpful. Please also keep in mind: in subsequent parts of the tutorial, |
| you will specify the <span class="emphasis"><em>metaModelPackage</em></span><a name="N1033A" class="indexterm"></a> in various component configurations in the workflow file, |
| like this:</p><pre class="programlisting"><metaModel id="mm" |
| class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelPackage value="data.DataPackage"/> |
| </metaModel> |
| </pre><p>In case of dynamic EMF, there has no metamodel package been |
| generated. So, you have to specify the metamodel file instead, that is, |
| the <code class="filename">.ecore</code> file you just created. Note that the |
| <code class="filename">.ecore</code> file has to be in the classpath to make this |
| work.</p><pre class="programlisting"><metaModel id="mm" |
| class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelFile value="data.ecore"/> |
| </metaModel></pre></div><div class="section" title="Generating code from the example model"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_generating_code"></a>Generating code from the example model</h2></div></div></div><div class="section" title="The workflow definition"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_the_workflow_definition"></a>The workflow definition</h3></div></div></div><p>To run the Xpand generator, you have to define a workflow. It |
| controls which steps (loading models, checking them, generating code) |
| the generator executes. For details on how workflow files work, please |
| take a look at the <span class="emphasis"><em>Modeling Workflow Engine Reference |
| Documentation</em></span>.</p><p>Create a <code class="filename">workflow.mwe</code> and a |
| <code class="filename">workflow.properties</code> in the <code class="filename">src</code> folder. The contents of these files is |
| shown below:</p><pre class="programlisting"><workflow> |
| <property file="workflow.properties"/> |
| |
| <bean class="org.eclipse.emf.mwe.utils.StandaloneSetup" > |
| <platformUri value=".."/> |
| <registerGeneratedEPackage value="data.DataPackage"/> |
| </bean> |
| |
| <component class="org.eclipse.emf.mwe.utils.Reader"> |
| <uri value="${modelFile}" /> |
| <modelSlot value="model" /> |
| </component> |
| </workflow></pre><p><code class="code">workflow.properties</code>:</p><pre class="programlisting">modelFile=platform:/resource/xpand.demo.emf.datamodel.generator/src/example.data |
| srcGenPath=src-gen |
| fileEncoding=ISO-8859-1</pre><p>The workflow tries to load stuff from |
| the classpath; so, for example, the |
| <code class="classname">data.DataPackage</code> class is resolved from the |
| classpath, as is the model file specified in the properties |
| (<code class="filename">modelFile=example.data</code>)</p><p>This instantiates the example model and stores in a workflow slot |
| named model. Note that in the <span class="emphasis"><em>metamodelPackage</em></span> |
| slot, you have to specify the EMF package object (here: |
| <code class="classname">data.DataPackage</code>), not the Java package (which |
| would be <span class="package">data</span> here).</p></div><div class="section" title="Running the workflow"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_running_the_workflow"></a>Running the workflow</h3></div></div></div><p>Before you actually run the workflow, make sure your metamodel can |
| be found on the classpath. In our case, this can be achieved by adding |
| the <code class="filename">xpand.demo.emf.datamodel</code> project to the plug-in |
| dependencies of <code class="filename">xpand.demo.emf.datamodel.generator</code>. |
| To do this, double click the file |
| <code class="filename">xpand.demo.emf.datamodel.generator/META-INF/MANIFEST.MF</code>. |
| The manifest editor will appear. Go to the |
| <span class="guimenu">Dependencies</span> tab and click on |
| <span class="guimenu">Add...</span> to add a few new dependencies.</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename">xpand.demo.emf.datamodel</code></p></li><li class="listitem"><p><code class="filename">org.eclipse.emf.mwe.utils</code></p></li><li class="listitem"><p><code class="filename">org.eclipse.emf.ecore.xmi</code></p></li><li class="listitem"><p><code class="filename">org.eclipse.jface.text</code></p></li><li class="listitem"><p><code class="filename">org.antlr.runtime</code></p></li><li class="listitem"><p><code class="filename">com.ibm.icu</code></p></li><li class="listitem"><p><code class="filename">org.eclipse.jdt.core</code></p></li></ul></div><div class="figure"><a name="emf_tutorial_add_metamodel_dependency"></a><p class="title"><b>Figure 15. Add metamodel dependency</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/add_metamodel_to_classpath.png" alt="Add metamodel dependency"></div></div></div><p><br class="figure-break">Do not forget to save the manifest file!</p><p>Now, you can run the workflow from within Eclipse: </p><div class="figure"><a name="emf_tutorial_run_workflow"></a><p class="title"><b>Figure 16. </b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/run_workflow.png" width="432"></div></div></div><p><br class="figure-break"></p><p>The following should be the output:</p><pre class="screen">INFO: -------------------------------------------------------------------------------------- |
| INFO: EMF Modeling Workflow Engine 1.2.1, Build v201206110920 |
| INFO: (c) 2005-2009 openarchitectureware.org and contributors |
| INFO: -------------------------------------------------------------------------------------- |
| INFO: running workflow: ../xpand.demo.emf.datamodel.generator/src/workflow.mwe |
| INFO: |
| 14.04.2010 15:49:18 org.eclipse.emf.mwe.utils.StandaloneSetup setPlatformUri |
| INFO: Registering platform uri '..' |
| 14.04.2010 15:49:18 org.eclipse.emf.mwe.utils.StandaloneSetup addRegisterGeneratedEPackage |
| INFO: Adding generated EPackage 'data.DataPackage' |
| 14.04.2010 15:49:18 org.eclipse.emf.mwe.core.container.CompositeComponent internalInvoke |
| INFO: Reader: Loading model from platform:/resource/xpand.demo.emf.datamodel.generator/src/example.data |
| 14.04.2010 15:49:19 org.eclipse.emf.mwe.core.WorkflowRunner executeWorkflow |
| INFO: workflow completed in 116ms!</pre></div><div class="section" title="Templates"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_templates"></a>Templates</h3></div></div></div><p>No code is generated yet. This is not surprising, since we did not |
| yet add any templates. Let us change this. Create a package |
| <span class="package">templates</span> in the <code class="filename">src</code>folder and within the package a file |
| called <code class="filename">Root.xpt</code>.</p><p>The <code class="filename">Root.xpt</code> looks as follows. By the way, if |
| you need to type the <span class="foreignphrase"><em class="foreignphrase">guillemets</em></span> |
| <a name="N103F1" class="indexterm"></a>(« and »), the editor provides keyboard shortcuts with |
| <span class="keycap"><strong>Ctrl</strong></span>+<span class="keycap"><strong><</strong></span> and <span class="keycap"><strong>Ctrl</strong></span>+<span class="keycap"><strong>></strong></span>.</p><pre class="programlisting">«DEFINE Root FOR data::DataModel» |
| «EXPAND Entity FOREACH entity» |
| «ENDDEFINE» |
| |
| «DEFINE Entity FOR data::Entity» |
| «FILE name + ".java"» |
| public class «name» { |
| «FOREACH attribute AS a» |
| // bad practice |
| private «a.type» «a.name»; |
| «ENDFOREACH» |
| } |
| «ENDFILE» |
| «ENDDEFINE» </pre><p>We have to extend the <code class="filename">workflow.mwe</code> file, in |
| order to use the template just written:</p><pre class="programlisting"><workflow> |
| <property file="workflow.properties"/> |
| |
| .. |
| |
| <component class="org.eclipse.emf.mwe.utils.Reader"> |
| <uri value="platform:/resource/${modelFile}" /> |
| .. |
| </workflow></pre><p>First, we clean up the directory where we want to put the |
| generated code.</p><pre class="programlisting"><component class="org.eclipse.emf.mwe.utils.DirectoryCleaner"> |
| <directory value="${srcGenPath}" /> |
| </component></pre><p>Then, we start the generator component. Its configuration is |
| slightly involved.</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"></pre><p>First of all, you have to define the metamodel. In our case, we |
| use the <code class="classname">EmfMetaModel</code><a name="N1041C" class="indexterm"></a> since we want to work with EMF models. Also, you have to |
| specific the class name of the EMF package that represents that |
| metamodel. It has to be on the classpath.</p><pre class="programlisting"> <metaModel id="mm" |
| class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"> |
| </metaModel></pre><p>Then, you have to define the <span class="emphasis"><em>entry statement</em></span> |
| for <span class="emphasis"><em>Xpand</em></span>. Knowing that the model slot contains an |
| instance of <code class="classname">data.DataModel</code> (the XmiReader had put |
| the first element of the model into that slot, and we know from the data |
| that it is a <code class="classname">DataModel</code>), we can write the |
| following statement. Again, notice that model refers to a slot name |
| here!</p><pre class="programlisting"> <expand value="templates::Root::Root FOR model"/></pre><p>We then specify where the generator should put the generated code |
| and that this generated code should be processed by a code |
| beautifier:</p><pre class="programlisting"> <outlet path="${srcGenPath}/"> |
| <postprocessor |
| class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| </outlet></pre><p>Now, we are almost done.</p><pre class="programlisting"> </component> |
| </workflow></pre><p>You also need to add the <span class="emphasis"><em>srcGenPath</em></span> to the |
| <code class="filename">workflow.properties</code> file.</p><pre class="programlisting">modelFile=example.data |
| srcGenPath=src-gen</pre></div><div class="section" title="Running the generator again"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_running_the_generator_again"></a>Running the generator again</h3></div></div></div><p>So, if you restart the generator now, you should get a file |
| generated that looks like this:</p><pre class="programlisting">public class Person { |
| // bad practice |
| public String lastName; |
| }</pre></div></div><div class="section" title="Checking Constraints with the Check Language"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_checking_contraints_with_check"></a>Checking Constraints with the <span class="emphasis"><em>Check</em></span> |
| Language</h2></div></div></div><p>An alternative to checking constraints with pure Java, is the |
| declarative constraint checking language |
| <span class="emphasis"><em>Check</em></span><a name="N1045D" class="indexterm"></a>. For details of this language take a look at the |
| <span class="emphasis"><em><a class="xref" href="#Check_language" title="Check">Check language</a></em></span> reference. We will |
| provide a simple example here.</p><div class="section" title="Defining the constraint"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_defining_the_constraint"></a>Defining the constraint</h3></div></div></div><p>We start by defining the constraint<a name="N1046D" class="indexterm"></a> itself. We create a new file called |
| <code class="filename">checks.chk</code> in the <code class="filename">src</code> folder of our project. It is important |
| that this file resides in the classpath! The file has the following |
| content:</p><pre class="programlisting">import data; |
| context Attribute ERROR |
| "Names must be more than one char long" : |
| name.length > 1;</pre><p>This constraint says that for the metaclass |
| <code class="classname">data::Attribute</code>, we require that the name be more |
| than one characters long. If this expression evaluates to false, the |
| error message given before the colon will be reported. A checks file can |
| contain any number of such constraints. They will be evaluated for all |
| instances of the respective metaclass.</p><p>To show a somewhat more involved constraint example, this one |
| ensures that the names of the attributes have to be unique:</p><pre class="programlisting">context Entity ERROR |
| "Names of Entity attributes must be unique": |
| attribute.forAll(a1| attribute.notExists(a2| a1 != a2 && a1.name == a2.name ) );</pre></div><div class="section" title="Integration into the workflow file"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_integration_into_the_workflow_file"></a>Integration into the workflow file</h3></div></div></div><p>The following piece of XML is the workflow file we have already |
| used above.</p><pre class="programlisting"><workflow> |
| <property file="workflow.properties"/> |
| |
| .. |
| |
| <component class="org.eclipse.emf.mwe.utils.Reader"> |
| <uri value="platform:/resource/${modelFile}" /> |
| .. |
| </component> |
| </workflow></pre><p>After reading the model, we add an additional component, namely |
| the <span class="emphasis"><em>CheckComponent</em></span>.</p><pre class="programlisting"><component |
| class="org.eclipse.xtend.check.CheckComponent"></pre><p>As with the code generator, we have to explain to the checker what |
| meta-meta-model and which metamodel we use.</p><pre class="programlisting"> <metaModel id="mm" |
| class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"> |
| </metaModel></pre><p>We then have to provide the checks file. The component tries to |
| load the file by appending <code class="filename">.chk</code> to the name and |
| searching the classpath – that is why it has to be located in the |
| classpath.</p><pre class="programlisting"> <checkFile value="checks"/></pre><p>Finally, we have to tell the engine on which model or part of the |
| model the checks should work. In general, you can use the |
| <code class="code"><expressionvalue="..."/></code> element to define an |
| arbitrary expression on slot contents. For our purpose, where we want to |
| use the complete EMF data structure in the model slot, we can use the |
| shortcut <span class="emphasis"><em>emfAllChildrenSlot</em></span> property, which returns |
| the complete subtree below the content element of a specific slot, |
| including the slot content element itself.</p><pre class="programlisting"> <emfAllChildrenSlot value="model"/> |
| </component></pre><p>Running the workflow produces an error in case the length of the |
| name is not greater than one. Again, it makes sense to add the |
| <code class="code">skipOnError="true"</code> to those subsequent component |
| invocations that need to be skipped in case the constraint check found |
| errors (typically code generators or transformers).</p></div></div><div class="section" title="Extensions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="emf_tutorial_extensions"></a>Extensions</h2></div></div></div><p>It is often the case that you need additional properties in the |
| templates; these properties should not be added to the metaclasses |
| directly, since they are often specific to the specific code generation |
| target and thus should not "pollute" the metamodel.</p><p>It is possible to define such extensions<a name="N104BB" class="indexterm"></a> external to the metaclasses. For details see the |
| <span class="emphasis"><em>Xtend Language Documentation</em></span>, we provide an simple |
| example here.</p><div class="section" title="Expression Extensions"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_expression_extensions"></a>Expression Extensions</h3></div></div></div><p>Assume we wanted to change the <span class="emphasis"><em>Attribute</em></span>s |
| part of the template as follows:</p><pre class="programlisting">«FOREACH attribute AS a» |
| private «a.type» «a.name»; |
| |
| public void «a.setterName()»( «a.type» value ) { |
| this.«a.name» = value; |
| } |
| |
| public «a.type» «a.getterName()»() { |
| return this.«a.name»; |
| } |
| «ENDFOREACH»</pre><p>To make this work, we need to define the |
| <code class="methodname">setterName()</code> and |
| <code class="methodname">getterName()</code> operations. We do this by writing |
| a so-called extension file; we call it <code class="filename">java.ext</code>. It |
| must have the <code class="filename">.ext</code> suffix to be recognized by |
| Xpand; the <span class="emphasis"><em>Java</em></span> name is because it contains |
| Java-generation specific properties. We put this file directly into the |
| <code class="filename">templates</code> directory under |
| <code class="filename">src</code>, i.e. directly next to the |
| <code class="filename">Root.xpt</code> file. The extension file looks as |
| follows:</p><p>First, we have to import the data metamodel; otherwise we would |
| not be able to use the <span class="emphasis"><em>Attribute</em></span> metaclass.</p><pre class="programlisting">import data;</pre><p>We can then define the two new operations |
| <code class="methodname">setterName</code> and |
| <code class="methodname">getterName</code>. Note that they take the type on |
| which they are called as their first parameter, a kind of "explicitly |
| this". After the colon we use an expression that returns the |
| to-be-defined value.</p><pre class="programlisting">String setterName(Attribute ele) : |
| 'set'+ele.name.toFirstUpper(); |
| |
| String getterName(Attribute ele) : |
| 'get'+ele.name.toFirstUpper();</pre><p>To make these extensions work, we have to add the following line |
| to the beginning of the <code class="filename">Root.xpt</code> template |
| file:</p><pre class="programlisting">«EXTENSION templates::java»</pre></div><div class="section" title="Java Extensions"><div class="titlepage"><div><div><h3 class="title"><a name="emf_tutorial_java_extensions"></a>Java Extensions<a name="N10509" class="indexterm"></a></h3></div></div></div><p>In case you cannot express the "business logic" for the expression |
| with the expression language, you can fall back to Java. Take a look at |
| the following extension definition file. It is called |
| <code class="filename">util.ext</code> and is located in <code class="filename">src/datamodel/generator/util</code>:</p><pre class="programlisting">String timestamp() : |
| JAVA datamodel.generator.util.TemplateUtils.timestamp();</pre><p>Here, we define an extension that is independent of a specific |
| model element, since it does not have a formal parameter! The |
| implementation of the extension is delegated to a static operation of a |
| Java class. Here is its implementation:</p><pre class="programlisting">public class TemplateUtils { |
| public static String timestamp() { |
| return String.valueOf( System.currentTimeMillis() ); |
| } |
| }</pre><p>This element can be used independent of any model element – it is |
| available globally.</p><p>Sometimes, it is necessary to access extensions not just from |
| templates and other Xtend files but also from Java code. The following |
| example is of this kind: We want to define properties that derive the |
| name of the implementation class from the entity name itself. The best |
| practice for this use case is to implement the derived property as a |
| Java method, as above. The following piece of code declares properties |
| for <code class="classname">Entity</code>:</p><pre class="programlisting">package datamodel; |
| |
| import data.Entity; |
| |
| public class EntityHelper { |
| |
| public static String className( Entity e ) { |
| return e.getName()+"Implementation"; |
| } |
| |
| public static String classFileName( Entity e ) { |
| return className(e)+".java"; |
| } |
| |
| }</pre><p>In addition, to access the properties from the template files, we |
| define an extension that uses the helper methods. The |
| <code class="filename">helper.ext</code> file is located right next to the helper |
| class shown above, i.e. in the <span class="package">datamodel</span> |
| package:</p><pre class="programlisting">import data; |
| |
| String className( Entity e ) : |
| JAVA datamodel.EntityHelper.className(data.Entity); |
| |
| String classFileName( Entity e ) : |
| JAVA datamodel.EntityHelper.classFileName(data.Entity);</pre><p>In addition to these new properties being accessible from Java |
| code by invoking <code class="code">EntityHelper.className(someEntity)</code>, we can |
| now write the following template:</p><pre class="programlisting">«EXTENSION templates::java» |
| «EXTENSION datamodel::generator::util::util» |
| «EXTENSION datamodel::helper» |
| |
| «DEFINE Root FOR data::DataModel» |
| «EXPAND Entity FOREACH entity» |
| «ENDDEFINE» |
| |
| «DEFINE Entity FOR data::Entity» |
| «FILE classFileName()» |
| // generated at «timestamp()» |
| public abstract class «className()» { |
| «FOREACH attribute AS a» |
| private «a.type» «a.name»; |
| public void «a.setterName()»( «a.type» value ) { |
| this.«a.name» = value; |
| } |
| |
| public «a.type» «a.getterName()»() { |
| return this.«a.name»; |
| } |
| «ENDFOREACH» |
| } |
| «ENDFILE» |
| «ENDDEFINE»</pre><p>For completeness, the following illustration shows the resulting |
| directory and file structure. </p><div class="figure"><a name="emf_tutorial_what_happened_so_far"></a><p class="title"><b>Figure 17. What has happened so far</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/emf_tutorial/generator_structure_so_far.png" alt="What has happened so far"></div></div></div><p><br class="figure-break"></p></div></div><div class="footnotes"><br><hr align="left" width="100"><div class="footnote"><p><sup>[<a href="#N100A4" name="ftn.N100A4" class="para">1</a>] </sup>To add children, right-click on the element to which you want |
| to add these children and select the type of the child from the |
| list. To configure the properties, open the properties dialog by |
| selecting <span class="guimenu">Show Properties View</span> at the bottom of |
| any of the context menus. Note that this is not an EMF tutorial. For |
| more details on how to build EMF (meta-)models, please refer to the |
| EMF documentation.</p></div><div class="footnote"><p><sup>[<a href="#N100B6" name="ftn.N100B6" class="para">2</a>] </sup>Attributes are children of type |
| <code class="classname">EAttribute</code>. Please fill in the |
| <span class="property">Name</span> and the <span class="property">EType</span> |
| properties.</p></div><div class="footnote"><p><sup>[<a href="#N1010E" name="ftn.N1010E" class="para">3</a>] </sup>Note: there are a couple of <span class="emphasis"><em>-1's</em></span> ... |
| don't miss the minus! Also, the containment flag is essential. If |
| containment is <code class="literal">true</code> you will be able to create |
| children of the referenced type, otherwise you can only reference |
| them.</p></div><div class="footnote"><p><sup>[<a href="#N1028B" name="ftn.N1028B" class="para">4</a>] </sup><span class="guimenu">Window</span> → <span class="guisubmenu">Preferences</span> → <span class="guisubmenu">General</span> → <span class="guisubmenu">Workspace</span> → <span class="guimenuitem">Text file encoding</span>. This is necessary to have the |
| <span class="foreignphrase"><em class="foreignphrase">guillemet</em></span> brackets available.</p></div><div class="footnote"><p><sup>[<a href="#N102A0" name="ftn.N102A0" class="para">5</a>] </sup><span class="guimenu">File</span> → <span class="guisubmenu">Import</span> → <span class="guisubmenu">General</span> → <span class="guimenuitem">Existing Project into Workspace</span></p></div><div class="footnote"><p><sup>[<a href="#N102AC" name="ftn.N102AC" class="para">6</a>] </sup>Unless you checked the option "Copy projects into |
| workspace"</p></div><div class="footnote"><p><sup>[<a href="#N102B2" name="ftn.N102B2" class="para">7</a>] </sup><span class="guimenu">File</span> → <span class="guisubmenu">New</span> → <span class="guisubmenu">Project</span> → <span class="guisubmenu">Xpand</span> → <span class="guimenuitem">Xpand Project</span></p></div></div></div><div class="part" title="Part I. Reference"><div class="titlepage"><div><div><h1 class="title"><a name="Reference"></a>Part I. Reference</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#core_reference">2. <span class="emphasis"><em>Xpand</em></span> / <span class="emphasis"><em>Xtend</em></span> / |
| <span class="emphasis"><em>Check</em></span> Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#r10_introduction">Introduction</a></span></dt><dt><span class="section"><a href="#r10_typesystem">Type System </a></span></dt><dd><dl><dt><span class="section"><a href="#r10_typesystem_types">Types</a></span></dt><dt><span class="section"><a href="#r10_builtintypes">Built-In Types</a></span></dt><dt><span class="section"><a href="#r10_metamodel_implementations">Metamodel Implementations (also known as |
| Meta-Metamodels)</a></span></dt><dt><span class="section"><a href="#r10_using_different_metamodels">Using different Metamodel implementations (also known as |
| Meta-Metamodels)</a></span></dt><dt><span class="section"><a href="#metamodel_reference">Metamodel Reference</a></span></dt></dl></dd><dt><span class="section"><a href="#r10_expressions_language">Expressions</a></span></dt><dd><dl><dt><span class="section"><a href="#r10_expressions_builtin">Literals and special operators for built-in types</a></span></dt><dt><span class="section"><a href="#r10_expressions_collection_operations">Special Collection operations</a></span></dt><dt><span class="section"><a href="#r10_expressions_if"><code class="methodname">if</code> expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_switch"><code class="methodname">switch</code> expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_chain">Chain expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_create"><code class="methodname">new</code> expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_globalvar">'GLOBALVAR' expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_multidispatch">Multi methods (multiple dispatch)</a></span></dt><dt><span class="section"><a href="#r10_expressions_casting">Casting</a></span></dt><dt><span class="section"><a href="#N10CD6">Xpand keywords and metamodel properties</a></span></dt></dl></dd><dt><span class="section"><a href="#Check_language"><span class="emphasis"><em>Check</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="#Check_language_description">Description of the <span class="emphasis"><em>Check</em></span> language</a></span></dt><dt><span class="section"><a href="#check_checkcomponent">The workflow component |
| <span class="emphasis"><em>CheckComponent</em></span></a></span></dt></dl></dd><dt><span class="section"><a href="#Xtend_language"><span class="emphasis"><em>Xtend</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="#N10DE7">Xtend files</a></span></dt><dt><span class="section"><a href="#N10E05">Comments</a></span></dt><dt><span class="section"><a href="#N10E15">Import Statements</a></span></dt><dt><span class="section"><a href="#N10E26">Extension Import Statement</a></span></dt><dt><span class="section"><a href="#N10E43">Extensions</a></span></dt><dt><span class="section"><a href="#N10EF3">Java Extensions</a></span></dt><dt><span class="section"><a href="#create_extension">Create Extensions (Model Transformation)</a></span></dt><dt><span class="section"><a href="#N11023">Calling Extensions From Java</a></span></dt><dt><span class="section"><a href="#N11067">WorkflowComponent</a></span></dt><dt><span class="section"><a href="#N1107E">Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xtend</em></span></a></span></dt></dl></dd><dt><span class="section"><a href="#xpand_reference_introduction"><span class="emphasis"><em>Xpand2</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="#xpand_reference_template_files_and_ecoding">Template files and encoding</a></span></dt><dt><span class="section"><a href="#xpand_reference_general_structure_of_template_files">General structure of template files</a></span></dt><dt><span class="section"><a href="#xpand_reference_statements_of_the_expand_language">Statements of the <span class="emphasis"><em>Xpand</em></span> language</a></span></dt><dt><span class="section"><a href="#xpand_reference_aspect-oriented_programming_in_xpand">Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xpand</em></span></a></span></dt><dt><span class="section"><a href="#xpand_reference_generator_workflow_component">Generator Workflow Component</a></span></dt><dt><span class="section"><a href="#aop_template_introduction">Example for using Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xpand</em></span></a></span></dt><dt><span class="section"><a href="#aop_template_the_problem">The Problem</a></span></dt><dt><span class="section"><a href="#aop_template_example">Example</a></span></dt><dt><span class="section"><a href="#aop_template_more_ao">More Aspect Orientation</a></span></dt></dl></dd><dt><span class="section"><a href="#r10_profiler">Profiler</a></span></dt></dl></dd><dt><span class="chapter"><a href="#builtin_api">3. Built-in types API documentation</a></span></dt><dd><dl><dt><span class="section"><a href="#Object.html"><code class="classname">Object</code></a></span></dt><dt><span class="section"><a href="#String.html"><code class="classname">String</code></a></span></dt><dt><span class="section"><a href="#Integer.html"><code class="classname">Integer</code></a></span></dt><dt><span class="section"><a href="#Boolean.html"><code class="classname">Boolean</code></a></span></dt><dt><span class="section"><a href="#Real.html"><code class="classname">Real</code></a></span></dt><dt><span class="section"><a href="#Collection.html"><code class="classname">Collection</code></a></span></dt><dt><span class="section"><a href="#List.html"><code class="classname">List</code></a></span></dt><dt><span class="section"><a href="#Set.html"><code class="classname">Set</code></a></span></dt><dt><span class="section"><a href="#xpand2_Type.html"><code class="classname">xpand2::Type</code></a></span></dt><dt><span class="section"><a href="#xpand2_Feature.html"><code class="classname">xpand2::Feature</code></a></span></dt><dt><span class="section"><a href="#xpand2_Property.html"><code class="classname">xpand2::Property</code></a></span></dt><dt><span class="section"><a href="#xpand2_Operation.html"><code class="classname">xpand2::Operation</code></a></span></dt><dt><span class="section"><a href="#xpand2_StaticProperty.html"><code class="classname">xpand2::StaticProperty</code></a></span></dt><dt><span class="section"><a href="#Void.html"><code class="classname">Void</code></a></span></dt><dt><span class="section"><a href="#xtend_AdviceContext.html"><code class="classname">xtend::AdviceContext</code></a></span></dt><dt><span class="section"><a href="#xpand2_Definition.html"><code class="classname">xpand2::Definition</code></a></span></dt><dt><span class="section"><a href="#xpand2_Iterator.html"><code class="classname">xpand2::Iterator</code></a></span></dt></dl></dd><dt><span class="chapter"><a href="#stdlib_reference">4. Stdlib</a></span></dt><dd><dl><dt><span class="section"><a href="#N123CE">Introduction</a></span></dt><dt><span class="section"><a href="#N123D6">Stdlib extensions</a></span></dt><dd><dl><dt><span class="section"><a href="#N123E3">IO extensions</a></span></dt><dt><span class="section"><a href="#N124C0">Counter extensions</a></span></dt><dt><span class="section"><a href="#N12520">Properties extensions</a></span></dt><dt><span class="section"><a href="#N1256E">Element properties extensions</a></span></dt><dt><span class="section"><a href="#N125B0">Issues extensions</a></span></dt><dt><span class="section"><a href="#N1262A">Naming extensions</a></span></dt><dt><span class="section"><a href="#N12684">Globalvar extensions</a></span></dt><dt><span class="section"><a href="#N1269B">Cloning extensions</a></span></dt><dt><span class="section"><a href="#N126DD">Cross references extensions</a></span></dt><dt><span class="section"><a href="#N12704">UID extensions</a></span></dt><dt><span class="section"><a href="#N1274E">Mixin extensions</a></span></dt><dt><span class="section"><a href="#N1278E">Tracing extensions</a></span></dt></dl></dd><dt><span class="section"><a href="#N12811">Stdlib workflow components</a></span></dt><dd><dl><dt><span class="section"><a href="#N12816">SystemCommand</a></span></dt><dt><span class="section"><a href="#N12879">SlotCopier</a></span></dt><dt><span class="section"><a href="#N128C4">SlotListAdder</a></span></dt><dt><span class="section"><a href="#N12913">SlotPrinter</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#eclipse_integration">5. Xpand Eclipse Integration</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_introduction">Introduction</a></span></dt><dt><span class="section"><a href="#eclipse_integration_installation">Installation</a></span></dt><dt><span class="section"><a href="#eclipse_integration_overview">Overview</a></span></dt><dt><span class="section"><a href="#eclipse_integration_file_decorations">File decorations</a></span></dt><dt><span class="section"><a href="#eclipse_integration_editors">Editors</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_editors_syntax_coloring">Syntax coloring</a></span></dt><dt><span class="section"><a href="#eclipse_integration_editors_code_completion">Code completion</a></span></dt><dt><span class="section"><a href="#eclipse_integration_editors_xpand_tag_delimiter"><span class="emphasis"><em>Xpand</em></span> tag delimiter creation support</a></span></dt></dl></dd><dt><span class="section"><a href="#eclipse_integration_preference_pages">Preference pages</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_preference_pages_meta_model_contributors">Metamodel contributors</a></span></dt><dt><span class="section"><a href="#eclipse_integration_preference_pages_global_preferences">Global preferences</a></span></dt><dt><span class="section"><a href="#eclipse_integration_preference_pages_preferences_per_project">Preferences per project</a></span></dt></dl></dd><dt><span class="section"><a href="#eclipse_integration_xpand_nature_builder">Xpand Nature and Xpand Builder</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_xpand_nature_builder_problem_markers">Problem markers</a></span></dt></dl></dd><dt><span class="section"><a href="#eclipse_integration_running_a_workflow">Running a workflow</a></span></dt></dl></dd><dt><span class="chapter"><a href="#incrementalGeneration">6. Incremental Generation</a></span></dt><dd><dl><dt><span class="section"><a href="#incrementalGeneration_background">Technical Background</a></span></dt><dt><span class="section"><a href="#incrementalGeneration_usage">Using Incremental Generation</a></span></dt><dd><dl><dt><span class="section"><a href="#incrementalGeneration_usage_facade">The Incremental Generation Facade</a></span></dt><dt><span class="section"><a href="#incrementalGeneration_usage_callback">The Incremental Generation Callback</a></span></dt></dl></dd><dt><span class="section"><a href="#incrementalGeneration_notes">Additional Notes</a></span></dt><dd><dl><dt><span class="section"><a href="#incrementalGeneration_limitations">Limitations</a></span></dt><dt><span class="section"><a href="#incrementalGeneration_performance">Performance Considerations</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#backend">7. Improve performance using the backend</a></span></dt><dd><dl><dt><span class="section"><a href="#backend_background">Technical background</a></span></dt><dd><dl><dt><span class="section"><a href="#backend_interpretation_background">How it works in interpreted mode</a></span></dt></dl></dd><dt><span class="section"><a href="#backend_usage">Using the backend</a></span></dt><dd><dl><dt><span class="section"><a href="#backend_quickstart">A quickstart</a></span></dt><dt><span class="section"><a href="#backend_compiler">Compiling sources to Java</a></span></dt><dt><span class="section"><a href="#backend_execution">Executing workflows using the backend</a></span></dt><dt><span class="section"><a href="#java_middleend">Implementing functions in Java - the Java Annotations |
| Middleend</a></span></dt></dl></dd><dt><span class="section"><a href="#call_functions_backend">Call functions registered at the backend from Java</a></span></dt></dl></dd><dt><span class="chapter"><a href="#uml_adapter">8. UML2 Adapter</a></span></dt><dd><dl><dt><span class="section"><a href="#uml_adapter_introduction">Introduction</a></span></dt><dt><span class="section"><a href="#uml_adapter_installation">Installation</a></span></dt><dt><span class="section"><a href="#uml_adapter_eclipse_setup">Setting up Eclipse</a></span></dt><dd><dl><dt><span class="section"><a href="#uml_adapter_setup_profiles">Profiles in Eclipse</a></span></dt></dl></dd><dt><span class="section"><a href="#uml_adapter_runtime_configuration">Runtime Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#uml_adapter_runtime_workflow">Workflow</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#xsd_reference">9. XSD Adapter</a></span></dt><dd><dl><dt><span class="section"><a href="#xsd_reference_prerequisites">Prerequisites</a></span></dt><dt><span class="section"><a href="#xsd_reference_overview">Overview</a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components">Workflow Components</a></span></dt><dd><dl><dt><span class="section"><a href="#xsd_reference_workflow_components_xsdmetamodel"> |
| <code class="classname">XSDMetaModel</code> |
| </a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components_xmlreader"> |
| <code class="classname">XMLReader</code> |
| </a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components_xmlwriter"> |
| <code class="classname">XMLWriter</code> |
| </a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components_xmlbeautifier"> |
| <code class="classname">XMLBeautifier</code> |
| </a></span></dt></dl></dd><dt><span class="section"><a href="#xsd_reference_xsd2ecore">Behind the scenes: Transforming XSD to Ecore</a></span></dt><dt><span class="section"><a href="#xsd_reference_declare_xsd">How to declare XML Schemas</a></span></dt></dl></dd></dl></div><div class="chapter" title="Chapter 2. Xpand / Xtend / Check Reference"><div class="titlepage"><div><div><h2 class="title"><a name="core_reference"></a>Chapter 2. <span class="emphasis"><em>Xpand</em></span> / <span class="emphasis"><em>Xtend</em></span> / |
| <span class="emphasis"><em>Check</em></span> Reference</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#r10_introduction">Introduction</a></span></dt><dt><span class="section"><a href="#r10_typesystem">Type System </a></span></dt><dd><dl><dt><span class="section"><a href="#r10_typesystem_types">Types</a></span></dt><dt><span class="section"><a href="#r10_builtintypes">Built-In Types</a></span></dt><dt><span class="section"><a href="#r10_metamodel_implementations">Metamodel Implementations (also known as |
| Meta-Metamodels)</a></span></dt><dt><span class="section"><a href="#r10_using_different_metamodels">Using different Metamodel implementations (also known as |
| Meta-Metamodels)</a></span></dt><dt><span class="section"><a href="#metamodel_reference">Metamodel Reference</a></span></dt></dl></dd><dt><span class="section"><a href="#r10_expressions_language">Expressions</a></span></dt><dd><dl><dt><span class="section"><a href="#r10_expressions_builtin">Literals and special operators for built-in types</a></span></dt><dt><span class="section"><a href="#r10_expressions_collection_operations">Special Collection operations</a></span></dt><dt><span class="section"><a href="#r10_expressions_if"><code class="methodname">if</code> expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_switch"><code class="methodname">switch</code> expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_chain">Chain expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_create"><code class="methodname">new</code> expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_globalvar">'GLOBALVAR' expression</a></span></dt><dt><span class="section"><a href="#r10_expressions_multidispatch">Multi methods (multiple dispatch)</a></span></dt><dt><span class="section"><a href="#r10_expressions_casting">Casting</a></span></dt><dt><span class="section"><a href="#N10CD6">Xpand keywords and metamodel properties</a></span></dt></dl></dd><dt><span class="section"><a href="#Check_language"><span class="emphasis"><em>Check</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="#Check_language_description">Description of the <span class="emphasis"><em>Check</em></span> language</a></span></dt><dt><span class="section"><a href="#check_checkcomponent">The workflow component |
| <span class="emphasis"><em>CheckComponent</em></span></a></span></dt></dl></dd><dt><span class="section"><a href="#Xtend_language"><span class="emphasis"><em>Xtend</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="#N10DE7">Xtend files</a></span></dt><dt><span class="section"><a href="#N10E05">Comments</a></span></dt><dt><span class="section"><a href="#N10E15">Import Statements</a></span></dt><dt><span class="section"><a href="#N10E26">Extension Import Statement</a></span></dt><dt><span class="section"><a href="#N10E43">Extensions</a></span></dt><dt><span class="section"><a href="#N10EF3">Java Extensions</a></span></dt><dt><span class="section"><a href="#create_extension">Create Extensions (Model Transformation)</a></span></dt><dt><span class="section"><a href="#N11023">Calling Extensions From Java</a></span></dt><dt><span class="section"><a href="#N11067">WorkflowComponent</a></span></dt><dt><span class="section"><a href="#N1107E">Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xtend</em></span></a></span></dt></dl></dd><dt><span class="section"><a href="#xpand_reference_introduction"><span class="emphasis"><em>Xpand2</em></span></a></span></dt><dd><dl><dt><span class="section"><a href="#xpand_reference_template_files_and_ecoding">Template files and encoding</a></span></dt><dt><span class="section"><a href="#xpand_reference_general_structure_of_template_files">General structure of template files</a></span></dt><dt><span class="section"><a href="#xpand_reference_statements_of_the_expand_language">Statements of the <span class="emphasis"><em>Xpand</em></span> language</a></span></dt><dt><span class="section"><a href="#xpand_reference_aspect-oriented_programming_in_xpand">Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xpand</em></span></a></span></dt><dt><span class="section"><a href="#xpand_reference_generator_workflow_component">Generator Workflow Component</a></span></dt><dt><span class="section"><a href="#aop_template_introduction">Example for using Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xpand</em></span></a></span></dt><dt><span class="section"><a href="#aop_template_the_problem">The Problem</a></span></dt><dt><span class="section"><a href="#aop_template_example">Example</a></span></dt><dt><span class="section"><a href="#aop_template_more_ao">More Aspect Orientation</a></span></dt></dl></dd><dt><span class="section"><a href="#r10_profiler">Profiler</a></span></dt></dl></div><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="r10_introduction"></a>Introduction</h2></div></div></div><p>The <span class="emphasis"><em>Xpand</em></span> generator framework provides textual |
| languages, that are useful in different contexts in the MDSD process (e.g. |
| validation, metamodel extensions, code generation, model transformation). |
| Each language (<span class="emphasis"><em>Check</em></span>, <span class="emphasis"><em>Xtend</em></span>, and |
| <span class="emphasis"><em>Xpand</em></span>) is built upon a common expression language and |
| type system. Therefore, they can operate on the same models, metamodels |
| and meta-metamodels and you do not need to learn the syntax again and |
| again, because it is always the same.</p><p>The expressions framework provides a uniform abstraction layer over |
| different meta-meta-models (e.g. EMF Ecore, Eclipse UML2, JavaBeans, XML |
| Schema etc.). Additionally, it offers a powerful, statically typed |
| expressions language, which is used in the various textual |
| languages.</p></div><div class="section" title="Type System"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="r10_typesystem"></a>Type System <a name="N10574" class="indexterm"></a> <a name="N1057A" class="indexterm"></a></h2></div></div></div><p>The abstraction layer on API basis is called a type system. It |
| provides access to built-in types and different registered metamodel |
| implementations. These registered metamodel implementations offer access |
| to the types they provide. The first part of this documentation describes |
| the type system. The expression sub-language is described afterwards in |
| the second part of this documentation. This differentiation is necessary |
| because the type system and the expression language are two different |
| things. The type system is a kind of reflection layer, that can be |
| extended with metamodel implementations. The expression language defines a |
| concrete syntax for executable expressions, using the type system.</p><p>The Java API described here is located in the |
| <span class="package">org.eclipse.xpand.type</span> package and is a part of the |
| subproject <span class="package">core.expressions</span>.</p><div class="section" title="Types"><div class="titlepage"><div><div><h3 class="title"><a name="r10_typesystem_types"></a>Types</h3></div></div></div><p>Every object (e.g. model elements, values, etc.) has a type. A |
| type contains properties and operations. In addition it might inherit |
| from other types (multiple inheritance is also possible, depending on |
| the underlying meta-meta-model).</p><div class="section" title="Type Names"><div class="titlepage"><div><div><h4 class="title"><a name="r10_typesystem_typenames"></a>Type Names</h4></div></div></div><p>Types have a simple name (e.g. <code class="classname">String</code>) |
| and an optional namespace used to distingish between two types with |
| the same name (e.g. <code class="classname">my::metamodel</code>). The |
| delimiter for name space fragments is a double colon |
| "<code class="classname">::</code>". A fully qualified name looks like this: |
| </p><pre class="programlisting">my::fully::qualified::MetaType</pre><p>The namespace and name used by a specific type is defined by the |
| corresponding <code class="classname">MetaModel</code><a name="N105A5" class="indexterm"></a> implementation. The <code class="classname">EmfMetaModel<a name="N105AB" class="indexterm"></a></code>, for instance, maps |
| <code class="classname">EPackages</code> to namespace and |
| <code class="classname">EClassifiers</code> to names.<a name="N105B5" class="indexterm"></a> <a name="N105B9" class="indexterm"></a> Therefore, the name of the Ecore element |
| <code class="classname">EClassifier</code> is called:</p><pre class="programlisting">ecore::EClassifier</pre><p>If you do not want to use namespaces (for whatever reason), you |
| can always implement your own metamodel and map the names |
| accordingly.</p></div><div class="section" title="Collection Type Names"><div class="titlepage"><div><div><h4 class="title"><a name="r10_typesystem_collection_typenames"></a>Collection Type Names</h4></div></div></div><p>The built-in type system also contains the following collection |
| types<a name="N105CA" class="indexterm"></a>: <code class="classname">Collection</code>, |
| <code class="classname">List</code> and <code class="classname">Set</code>. Because |
| the expressions language is statically type checked and we do not like |
| casts and <code class="classname">ClassCastExceptions</code>, we introduced |
| the concept of <span class="emphasis"><em>parameterized types</em></span>. The type |
| system does not support full featured generics, because we do not need |
| them.</p><p>The syntax is:</p><pre class="programlisting">Collection[my::Type] |
| List[my::Type] |
| Set[my::Type] |
| </pre></div><div class="section" title="Features"><div class="titlepage"><div><div><h4 class="title"><a name="r10_typesystem_features"></a>Features</h4></div></div></div><p>Each type offers features. The type (resp. the metamodel) is |
| responsible for mapping the features. There are three different kinds |
| of features: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Properties</p></li><li class="listitem"><p>Operations</p></li><li class="listitem"><p>Static properties</p></li></ul></div><p><span class="emphasis"><em>Properties</em></span><a name="N105F4" class="indexterm"></a> are straight forward: They have a name and a type. They |
| can be invoked on instances of the corresponding type. The same is |
| true for <span class="emphasis"><em>Operations</em></span><a name="N105FC" class="indexterm"></a>. But in contrast to properties, they can have |
| parameters. <span class="emphasis"><em>Static properties</em></span> <a name="N10605" class="indexterm"></a>are the equivalent to enums or constants. They must be |
| invoked statically and they do not have parameters.</p></div></div><div class="section" title="Built-In Types"><div class="titlepage"><div><div><h3 class="title"><a name="r10_builtintypes"></a>Built-In Types<a name="N1060F" class="indexterm"></a></h3></div></div></div><p>As mentioned before, the expressions framework has several |
| built-in types that define operations and properties. In the following, |
| we will give a rough overview of the types and their features. We will |
| not document all of the operations here, because the built-in types will |
| evolve over time and we want to derive the documentation from the |
| implementation (model-driven, of course). For a complete reference, |
| consult the generated <a class="link" href="#">API |
| documentation</a>.</p><div class="section" title="Object"><div class="titlepage"><div><div><h4 class="title"><a name="r10_builtintypes_object"></a><code class="classname">Object<a name="N1061D" class="indexterm"></a></code></h4></div></div></div><p><code class="classname">Object</code> defines a couple of basic |
| operations, like <code class="methodname">equals()</code>. The property |
| metaType provides access to Xpand's type for that Object. Every type |
| has to extend <code class="classname">Object</code>.</p></div><div class="section" title="Void"><div class="titlepage"><div><div><h4 class="title"><a name="r10_builtintypes_void"></a><code class="classname">Void</code><a name="N10631" class="indexterm"></a></h4></div></div></div><p>The <code class="classname">Void</code> type can be specified as the |
| return type for operations, although it is not recommended, because |
| whenever possible expressions should be free of side effects whenever |
| possible. The only possible value is <code class="varname">null</code>. |
| Sometimes it might be useful to use <code class="classname">Void</code> as an |
| parameter type, if you want to be able to call a function for |
| different argument types and also supply a valid implementation when |
| the function is invoked with <code class="varname">null</code>.</p></div><div class="section" title="Simple types (Data types)"><div class="titlepage"><div><div><h4 class="title"><a name="r10_builtintypes_simple"></a>Simple types (Data types)</h4></div></div></div><a name="N10648" class="indexterm"></a><p>The type system doesn't have a concept data type. Data types are |
| just types. As in OCL, we support the following types: |
| <code class="classname">String</code>, <code class="classname">Boolean</code>, |
| <code class="classname">Integer</code>, <code class="classname">Real</code>. |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="classname">String</code><a name="N10660" class="indexterm"></a>: A rich and convenient |
| <code class="classname">String</code> library is especially important |
| for code generation. The type system supports the '+' operator |
| for concatenation, the usual |
| <code class="classname">java.lang.String</code> operations |
| (<code class="methodname">length()</code>, etc.) and some special |
| operations (like <code class="methodname">toFirstUpper()</code>, |
| <code class="methodname">toFirstLower()</code>, regular expressions, |
| etc. often needed in code generation templates).</p></li><li class="listitem"><p><code class="classname">Boolean</code><a name="N10677" class="indexterm"></a>: <code class="classname">Boolean</code> offers the usual |
| operators (Java syntax): &&, ||, !, etc.</p></li><li class="listitem"><p><code class="classname">Integer</code><a name="N10682" class="indexterm"></a> and <code class="classname">Real</code><a name="N10688" class="indexterm"></a>: <code class="classname">Integer</code> and |
| <code class="classname">Real</code> offer the usual compare operators |
| (<,>,<=,>=) and simple arithmetics (+,-,*,/). Note |
| that <span class="emphasis"><em><code class="classname">Integer</code> extends |
| <code class="classname">Real</code>!</em></span></p></li></ul></div></div><div class="section" title="Collection types"><div class="titlepage"><div><div><h4 class="title"><a name="r10_builtintypes_collections"></a>Collection types</h4></div></div></div><a name="N1069D" class="indexterm"></a><p>The type system has three different Collection types. |
| <code class="classname">Collection</code><a name="N106A6" class="indexterm"></a> is the base type, it provides several operations known |
| from <code class="classname">java.util.Collection</code>. The other two types |
| (<code class="classname">List</code><a name="N106AF" class="indexterm"></a>, <code class="classname">Set<a name="N106B5" class="indexterm"></a></code>) correspond to their |
| <span class="package">java.util</span> equivalents, too.</p></div><div class="section" title="Type system types"><div class="titlepage"><div><div><h4 class="title"><a name="r10_builtintypes_typesystem_types"></a>Type system types</h4></div></div></div><p>The type system describes itself, hence, there are types for the |
| different concepts. These types are needed for reflective programming. |
| To avoid confusion with metatypes with the same name (it is not |
| unusual to have a metatype called <code class="classname">Operation</code>, |
| for instance) we have prefixed all of the types with the namespace |
| <code class="classname">xpand2</code>. We have:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="classname">xpand2::Type</code></p></li><li class="listitem"><p><code class="classname">xpand2::Feature</code></p></li><li class="listitem"><p><code class="classname">xpand2::Property</code></p></li><li class="listitem"><p><code class="classname">xpand2::StaticProperty</code></p></li><li class="listitem"><p><code class="classname">xpand2::Operation</code></p></li></ul></div><p>You should be aware that if you name a type by name in an |
| expression the object you get is in fact an |
| <code class="classname">xpand2::Type</code>. A common use case is to prove |
| that an object is of some type or its subtype, using the |
| <code class="methodname">instanceOf()</code> operation or exactly of one |
| type.</p><pre class="programlisting">// results to true, if the result of someExpression is of type MyType or its subtypes |
| MyType.isInstance(someExpression) |
| |
| // results to true, if the result of someExpression is exactly of type MyType |
| someExpression.metaType == MyType</pre><p>Note that this should be |
| only used when really required. The recommended way to handle |
| alternative implementations for a type hierarchy is using <a class="link" href="#">Multiple Dispatch</a>.</p></div></div><div class="section" title="Metamodel Implementations (also known as Meta-Metamodels)"><div class="titlepage"><div><div><h3 class="title"><a name="r10_metamodel_implementations"></a>Metamodel Implementations (also known as |
| Meta-Metamodels)<a name="N106F2" class="indexterm"></a></h3></div></div></div><p>By default, the type system only knows the <a class="link" href="#">built-in types</a>. In order to register your own |
| metatypes (e.g. <code class="classname">Entity</code> or |
| <code class="classname">State</code>), you need to register a respective |
| metamodel implementation with the type system. Within a metamodel |
| implementation the <span class="emphasis"><em>Xpand</em></span> type system elements |
| (<code class="classname">Type</code>, <code class="classname">Property</code>, |
| <a name="N1070A" class="indexterm"></a><code class="classname"> Operation) </code><a name="N1070F" class="indexterm"></a> are mapped to an arbitrary other type system (e.g. Java |
| reflections, Ecore or XML Schema).</p><div class="section" title="Example JavaMetaModel"><div class="titlepage"><div><div><h4 class="title"><a name="r10_metamodel_example_java"></a>Example JavaMetaModel</h4></div></div></div><p>For instance, if you want to have the following JavaBean act as |
| a metatype (i.e. your model contains instances of the type):</p><pre class="programlisting">public class Attribute { |
| private String name; |
| private String type; |
| public String getName() { |
| return name; |
| } |
| public void setName(String name) { |
| this.name = name; |
| } |
| public String getType() { |
| return type; |
| } |
| public void setType(String type) { |
| this.type = type; |
| } |
| } |
| </pre><p>You need to use the <code class="classname">JavaMetaModel</code> |
| <a name="N10721" class="indexterm"></a> implementation which uses the ordinary Java reflection |
| layer in order to map access to the model.</p><p>So, if you have the following expression in e.g. |
| <span class="emphasis"><em>Xpand</em></span>:</p><pre class="programlisting">myattr.name.toFirstUpper()</pre><p>and <code class="varname">myattr</code> is the name of a local variable |
| pointing to an instance of <code class="classname">Attribute</code>. The |
| <span class="emphasis"><em>Xpand</em></span> type system asks the metamodel |
| implementations, if they 'know' a type for the instance of Attribute. |
| If you have the <code class="classname">JavaMetaModel</code> registered it |
| will return an <code class="classname">xpand2::Type</code> which maps to the |
| underlying Java class. When the type is asked if it knows a property |
| '<code class="varname">name</code>', it will inspect the Java class using the |
| Java reflection API.</p><p>The JavaMetaModel implementation shipped with |
| <span class="emphasis"><em>Xpand</em></span> can be configured with a strategy |
| [GOF95-Pattern] in order to control or change the mapping. For |
| instance, the <code class="classname">JavaBeansStrategy</code> maps getter and |
| setter methods to simple properties, so we would use this strategy for |
| the example above.</p></div><div class="section" title="Eclipse IDE MetaModelContributors"><div class="titlepage"><div><div><h4 class="title"><a name="r10_metamodel_contributors"></a>Eclipse IDE MetaModelContributors</h4></div></div></div><p>You should know that for each <code class="classname">Metamodel</code> |
| <a name="N10751" class="indexterm"></a>implementation you use at runtime, you need to have a so |
| called <code class="classname">MetamodelContributor</code> extension for the |
| plugins to work with. If you just use one of the standard metamodel |
| implementations (EMF, UML2 or Java) you don't have to worry about it, |
| since <span class="emphasis"><em>Xpand</em></span> is shipped with respective |
| MetamodelContributors (see the corresponding docs for details). If you |
| need to implement your own |
| <code class="classname">MetamodelContributor</code><a name="N1075D" class="indexterm"></a> you should have a look at the Eclipse plug-in reference |
| doc.</p></div><div class="section" title="Configuring Metamodel implementations with the workflow"><div class="titlepage"><div><div><h4 class="title"><a name="r10_metamodel_workflow"></a>Configuring Metamodel implementations with the workflow</h4></div></div></div><p>You need to configure your <span class="emphasis"><em>Xpand</em></span> language |
| components with the respective metamodel implementations.</p><p>A possible configuration of the <code class="classname">Xpand2</code> |
| generator component looks like this:</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| <metaModel class="org.eclipse.type.emf.EmfMetaModel"> |
| <metaModelPackage value="my.generated.MetaModel1Package"/> |
| </metaModel> |
| <metaModel class="org.eclipse.type.emf.EmfMetaModel"> |
| <metaModelFile value="my/java/package/metamodel2.ecore"/> |
| </metaModel> |
| ... |
| </component> |
| </pre><p>In this example the <code class="classname">EmfMetaModel</code> |
| implementation is configured two times. This means that we want to use |
| two metamodels at the same time, both based on EMF. The |
| <span class="property">metaModelPackage</span> property is a property that is |
| specific to the <code class="classname">EmfMetaModel</code> (located in the |
| <code class="filename">org.eclipse.xtend.typesystem.emf</code> plugin). It |
| points to the generated <code class="classname">EPackages</code> interface. |
| The second meta model is configured using the Ecore file. You do no |
| need to have a generated Ecore model for <span class="emphasis"><em>Xpand</em></span> in |
| order to work. The <code class="classname">EmfMetaModel</code> works with |
| dynamic EMF models just as it works with generated EMF models.</p><p>Note that is recommended to prefer the |
| <code class="classname">EmfRegistryMetaModel</code> instead of the |
| <code class="classname">EmfMetaModel</code>, although |
| <code class="classname">EmfMetaModel</code> is derived from the |
| <code class="classname">EmfRegistryMetaModel</code>. Further it is recommended |
| to use platform URIs (see <a class="ulink" href="http://help.eclipse.org/galileo/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/common/util/URI.html" target="_new">API |
| Doc URI</a>) to refer to EMF resources.</p><p>The use of platform URIs in the workflow requires setting up EMF |
| for standalone execution with the |
| <code class="classname">StandaloneSetup</code> class from the |
| <code class="classname">org.eclipse.emf.mwe.utils</code> plugin. Further, |
| StandaloneSetup is used to register known EMF packages. An equivalent |
| workflow configuration for the sample above would look like |
| this:</p><pre class="programlisting"><bean class="org.eclipse.emf.mwe.utils.StandaloneSetup"> |
| <platformUri value=".."/> |
| <registerGeneratedEPackage value="my.generated.MetaModel1Package"/> |
| <registerEcoreFile value="platform:/resource/my/java/package/metamodel2.ecore"/> |
| </bean> |
| ... |
| <component class="org.eclipse.xpand2.Generator"> |
| <metaModel class="org.eclipse.type.emf.EmfRegistryMetaModel"/> |
| ... |
| </component> |
| </pre><p>The <code class="classname">StandaloneSetup</code> is given the path |
| to the platform. This is the path to which platform resource URIs are |
| resolved relative to. It usually points to the workspace or check out |
| location of the plugin project, which is usually one directory above |
| the working directory in which a workflow is executed.</p><p>Metamodel instances are often shared between different |
| components that make use of expressions (most notably the Xpand |
| <code class="classname">Generator</code>, |
| <code class="classname">XtendComponent</code> and |
| <code class="classname">CheckComponent</code>). Normally you don't want that a |
| Metamodel instance configured and instantiated for each workflow |
| component. MWE lets you instantiate a class using the |
| <code class="methodname"><bean></code> tag and by giving the bean an id |
| value, this same instance can be referred to using the idRef |
| attribute. This would lead to this workflow:</p><pre class="programlisting"><bean class="org.eclipse.emf.mwe.utils.StandaloneSetup"> |
| <platformUri value=".."/> |
| <registerGeneratedEPackage value="my.generated.MetaModel1Package"/> |
| <registerEcoreFile value="platform:/resource/my/java/package/metamodel2.ecore"/> |
| </bean> |
| <bean id="mm_emf" class="org.eclipse.type.emf.EmfRegistryMetaModel"/> |
| ... |
| <component class="org.eclipse.xpand2.Generator"> |
| <metaModel idRef="mm_emf"/> |
| ... |
| </component> |
| </pre></div></div><div class="section" title="Using different Metamodel implementations (also known as Meta-Metamodels)"><div class="titlepage"><div><div><h3 class="title"><a name="r10_using_different_metamodels"></a>Using different Metamodel implementations (also known as |
| Meta-Metamodels)</h3></div></div></div><p>With Xpand you can work on different kinds of Model |
| representations at the same time in a transparent manner. One can work |
| with EMF models, XML DOM models, and simple JavaBeans in the same |
| <span class="emphasis"><em>Xpand</em></span> template. You just need to configure the |
| respective MetaModel implementations.</p><p>If you want to do so you need to know how the type lookup works. |
| Let us assume that we have an EMF metamodel <a name="N107C8" class="indexterm"></a> and a model based on some Java classes. Then the |
| following would be a possible configuration:</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| <metaModel class="org.eclipse.internal.xtend.type.impl.java.JavaMetaModel"/> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"> |
| <metaModelFile value="my/java/package/metamodel.ecore"/> |
| </metaModel> |
| |
| ... |
| </component> |
| </pre><p>When the runtime needs to access a property of a given object, it |
| asks the metamodels in the configured order. Let us assume that our |
| model element is an instance of the Java type |
| <code class="classname">org.eclipse.emf.ecore.EObject</code> and it is a dynamic |
| instance of an EMF EClass <code class="classname">MyType</code>.</p><p>We have <span class="emphasis"><em>three</em></span> Metamodels: </p><div class="orderedlist"><a name="N107DD" class="indexterm"></a><ol class="orderedlist" type="1"><li class="listitem"><p>Built-Ins (always the first one)</p></li><li class="listitem"><p>JavaMetaModel</p></li><li class="listitem"><p>EMFMetaModel - metamodel.ecore</p></li></ol></div><p>The first one will return the type <code class="classname">Object</code> |
| (not <code class="classname">java.lang.Object</code> but |
| <code class="classname">Object</code> of <span class="emphasis"><em>Xpand</em></span>!). At this |
| point the type <code class="classname">Object</code> best fits the request, so |
| it will act as the desired type.</p><p>The second metamodel returns a type called |
| <code class="classname">org::eclipse::emf::ecore::EObject</code> The type system |
| will check if the returned type is a specialization of the current |
| 'best-fit' type (<code class="classname">Object</code>). It is, because it |
| extends <code class="classname">Object</code> (Every metatype has to extend |
| <code class="classname">Object</code>). At this time the type system assumes |
| <code class="classname">org::eclipse::emf::ecore::EObject</code> to be the |
| desired type.</p><p>The third metamodel will return |
| <code class="classname">metamodel::MyType</code> which is the desired type. But |
| unfortunately it doesn't extend |
| <code class="classname">org::eclipse::emf::ecore::EObject</code> as it has |
| nothing to do with those Java types. Instead it extends |
| <code class="classname">emf::EObject</code> which extends |
| <code class="classname">Object</code>.</p><p>We need to swap the configuration of the two metamodels to get the |
| desired type.</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelFile value="my/java/package/metamodel.ecore"/> |
| </metaModel> |
| <metaModel class="org.eclipse.internal.xtend.type.impl.java.JavaMetaModel"/> |
| |
| ... |
| </component></pre><p>The order of the metamodels is important for the work within the |
| Xpand-editors. The metamodels to work with can be configured inside the |
| <span class="emphasis"><em>Xtend/Xpand</em></span> -properties dialog. The |
| <span class="emphasis"><em>Activated metamodel contributors</em></span> table is a ordered |
| list. The more specific metamodels have to be placed at the top of the |
| list. </p><div class="mediaobject"><img src="images/eclipse_integration/projectProperties.png"></div></div><div class="section" title="Metamodel Reference"><div class="titlepage"><div><div><h3 class="title"><a name="metamodel_reference"></a>Metamodel Reference</h3></div></div></div><a name="N10835" class="indexterm"></a><p>In the following, each of the built-in metamodels that come with |
| <span class="emphasis"><em>Xpand</em></span> will be documented. Furthermore, there will |
| be some guidelines on how to implement your own metamodel.</p><div class="section" title="EMF Metamodels"><div class="titlepage"><div><div><h4 class="title"><a name="emf_metamodels"></a>EMF Metamodels</h4></div></div></div><p>This section will describe the metamodels that can be used for |
| EMF models. <span class="strong"><strong>Please note that you have to |
| execute one of the setup utility classes, <code class="classname">Setup</code> |
| or <code class="classname">StandaloneSetup</code>, in your workflow before you |
| can use one of the EMF metamodels.</strong></span></p><div class="section" title="The EMF Registry Metamodel (org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel)"><div class="titlepage"><div><div><h5 class="title"><a name="emfregistry_metamodel"></a>The EMF Registry Metamodel |
| (org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel)</h5></div></div></div><a name="N10852" class="indexterm"></a><a name="N10857" class="indexterm"></a><p>This metamodel looks for the referenced metamodels in the |
| global EMF model registry. This means, when using this metamodel, |
| only models that are registered in this global EMF model registry |
| will be accessible from within the metamodel.</p><p>This metamodel provides the following configuration |
| property:</p><div class="table"><a name="properties_emfregistrymetamodel"></a><p class="title"><b>Table 1. Properties of |
| <code class="classname">EmfRegistryMetaModel</code></b></p><div class="table-contents"><table summary="Properties of |
| EmfRegistryMetaModel" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"><code class="varname">useSingleGlobalResourceSet</code></td><td align="left">This boolean property determines the way resource |
| sets are used. If set to <span class="emphasis"><em>true</em></span>, all |
| model resources will be stored in a single global resource |
| set. Otherwise, a separate resource set will be used for |
| each model resource.</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="The EMF Metamodel (org.eclipse.xtend.typesystem.emf.EmfMetaModel)"><div class="titlepage"><div><div><h5 class="title"><a name="emf_metamodel"></a>The EMF Metamodel |
| (org.eclipse.xtend.typesystem.emf.EmfMetaModel)</h5></div></div></div><a name="N10883" class="indexterm"></a><a name="N10888" class="indexterm"></a><p>This metamodel is a specialized version of the <a class="xref" href="#emfregistry_metamodel" title="The EMF Registry Metamodel (org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel)">EMF registry metamodel</a>. In addition to the features of |
| the former, it allows to specify an unregistered model in different |
| ways that will be added to the metamodel.</p><p>This metamodel provides the following configuration |
| properties:</p><div class="table"><a name="properties_emfmetamodel"></a><p class="title"><b>Table 2. Properties of <code class="classname">EmfMetaModel</code></b></p><div class="table-contents"><table summary="Properties of EmfMetaModel" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"><code class="varname">useSingleGlobalResourceSet</code></td><td align="left">This boolean property determines the way resource |
| sets are used. If set to <span class="emphasis"><em>true</em></span>, all |
| model resources will be stored in a single global resource |
| set. Otherwise, a separate resource set will be used for |
| each model resource.</td></tr><tr><td align="left"><code class="varname">metaModelFile</code></td><td align="left">Sets the path to the Ecore file that will be added to |
| the metamodel.</td></tr><tr><td align="left"><code class="varname">metaModelDescriptor</code></td><td align="left">Adds a model to the metamodel by specifying the name |
| of an EPackage descriptor class.</td></tr><tr><td align="left"><code class="varname">metaModelPackage</code></td><td align="left">Adds a model to the metamodel by specifying the name |
| of an EPackage.</td></tr></tbody></table></div></div><br class="table-break"></div></div><div class="section" title="UML Metamodels"><div class="titlepage"><div><div><h4 class="title"><a name="uml_metamodels"></a>UML Metamodels</h4></div></div></div><p><span class="emphasis"><em>Xpand</em></span> also provides several metamodels that |
| allow to use UML models in conjunction with this model-to-text |
| generation framework. <span class="strong"><strong>Please note that you |
| have to execute the setup utility class <code class="classname">Setup</code> |
| in your workflow before you can use one of the UML |
| metamodels</strong></span></p><div class="section" title="The UML2 Metamodel (org.eclipse.xtend.typesystem.uml2.UML2MetaModel)"><div class="titlepage"><div><div><h5 class="title"><a name="uml2_metamodel"></a>The UML2 Metamodel |
| (org.eclipse.xtend.typesystem.uml2.UML2MetaModel)</h5></div></div></div><a name="N108D8" class="indexterm"></a><a name="N108DD" class="indexterm"></a><p>This metamodel is a specialized version of the <span class="emphasis"><em><a class="xref" href="#emf_metamodel" title="The EMF Metamodel (org.eclipse.xtend.typesystem.emf.EmfMetaModel)">EMF metamodel</a></em></span>. It provides access to UML2 |
| models, and it has the following configuration properties:</p><div class="table"><a name="properties_uml2metamodel"></a><p class="title"><b>Table 3. Properties of <code class="classname">UML2MetaModel</code></b></p><div class="table-contents"><table summary="Properties of UML2MetaModel" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"><code class="varname">useSingleGlobalResourceSet</code></td><td align="left">This boolean property determines the way resource |
| sets are used. If set to <span class="emphasis"><em>true</em></span>, all |
| model resources will be stored in a single global resource |
| set. Otherwise, a separate resource set will be used for |
| each model resource.</td></tr><tr><td align="left"><code class="varname">modelFile</code></td><td align="left">Sets the path to the UML2 model file that will be |
| added to the metamodel.</td></tr></tbody></table></div></div><br class="table-break"><p>This implementation will be rarely used, since usually |
| profiled UML models will be used and therefore the Profile Metamodel |
| is.</p></div><div class="section" title="The UML2 Profile Metamodel (org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel)"><div class="titlepage"><div><div><h5 class="title"><a name="uml2profile_metamodel"></a>The UML2 Profile Metamodel |
| (org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel)</h5></div></div></div><a name="N10913" class="indexterm"></a><a name="N10918" class="indexterm"></a><p>This metamodel allows to apply UML profiles to UML2 models, |
| and extends the UML2 Metamodel. It has the following configuration |
| properties:</p><div class="table"><a name="properties_profilemetamodel"></a><p class="title"><b>Table 4. Properties of |
| <code class="classname">ProfileMetaModel</code></b></p><div class="table-contents"><table summary="Properties of |
| ProfileMetaModel" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"><code class="varname">useSingleGlobalResourceSet</code></td><td align="left">This boolean property determines the way resource |
| sets are used. If set to <span class="emphasis"><em>true</em></span>, all |
| model resources will be stored in a single global resource |
| set. Otherwise, a separate resource set will be used for |
| each model resource.</td></tr><tr><td align="left"><code class="varname">modelFile</code></td><td align="left">Sets the path to the UML2 model file that will be |
| added to the metamodel. Use resource URIs for the |
| values.</td></tr><tr><td align="left"><code class="varname">profile</code></td><td align="left">Sets the path to the UML profile that will be applied |
| to the UML2 model. This property can be used multiple times |
| if more than one profile is used. Use resource URIs for the |
| values.</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="The XMI reader (org.eclipse.xtend.typesystem.uml2.profile.ProfilingExtensions.XmiReader)"><div class="titlepage"><div><div><h5 class="title"><a name="xmi_reader"></a>The XMI reader |
| (org.eclipse.xtend.typesystem.uml2.profile.ProfilingExtensions.XmiReader)</h5></div></div></div><a name="N1094E" class="indexterm"></a><a name="N10951" class="indexterm"></a><p>The XMI reader component is important when working with UML |
| models. It allows to read out a model stored in an XMI file and put |
| its contents into a model slot.</p><p>The <code class="classname">XMIReader</code> component provides the |
| following configurable properties:</p><div class="table"><a name="properties_xmireader"></a><p class="title"><b>Table 5. Properties of <code class="classname">XMIReader</code></b></p><div class="table-contents"><table summary="Properties of XMIReader" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left">metaModelFile</td><td align="left">Sets the path to the Ecore file that will be added to |
| the metamodel.</td></tr><tr><td align="left">metaModelDescriptor</td><td align="left">Adds a model to the metamodel by specifying the name |
| of an EPackage descriptor class.</td></tr><tr><td align="left">metaModelPackage</td><td align="left">Adds a model to the metamodel by specifying the name |
| of an EPackage.</td></tr><tr><td align="left">outputSlot</td><td align="left">Sets the name of the model slot where the read model |
| will be stored in.</td></tr><tr><td align="left">firstElementOnly</td><td align="left">This boolean property determines if only the first |
| model element of the XMI file will be used. If set to |
| <span class="emphasis"><em>true</em></span>, only the first model element will |
| be used, all other elements will be ignored. Otherwise, all |
| model elements in the XMI file will be used.</td></tr></tbody></table></div></div><br class="table-break"></div></div><div class="section" title="The Java Metamodel (org.eclipse.internal.xtend.type.impl.java.JavaMetaModel)"><div class="titlepage"><div><div><h4 class="title"><a name="java_metamodel"></a>The Java Metamodel |
| (org.eclipse.internal.xtend.type.impl.java.JavaMetaModel)</h4></div></div></div><a name="N10993" class="indexterm"></a><a name="N10998" class="indexterm"></a><p>The Java metamodel allows normal Java classes as metatypes for |
| your metamodel. The <code class="classname">JavaMetaClass</code> uses the |
| strategy pattern to define how the elements are exactly mapped to the |
| metamodel elements. There is a class called |
| <code class="classname">org.eclipse.internal.xtend.type.impl.java.JavaBeansMetaModel</code> |
| that is preconfigured with a strategy that maps simple Java beans onto |
| the metamodel elements.</p><p>The Java metamodel has no configurable properties.</p></div><div class="section" title="The XSD Metamodel (org.eclipse.xtend.typesystem.xsd.XSDMetaModel)"><div class="titlepage"><div><div><h4 class="title"><a name="xsd_metamodel"></a>The XSD Metamodel |
| (org.eclipse.xtend.typesystem.xsd.XSDMetaModel)</h4></div></div></div><a name="N109AA" class="indexterm"></a><a name="N109AF" class="indexterm"></a><p>The XSD metamodel provides access to models implemented in the |
| XML Schema Definition language. It has the following configuration |
| properties:</p><div class="table"><a name="properties_xsdmetamodel"></a><p class="title"><b>Table 6. Properties of <code class="classname">XSDMetaModel</code></b></p><div class="table-contents"><table summary="Properties of XSDMetaModel" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"><code class="varname">id</code></td><td align="left">Sets the ID of the current model.</td></tr><tr><td align="left"><code class="varname">registerPackagesGlobally</code></td><td align="left">This boolean property determines if the model packages |
| will be registered globally. If set to |
| <span class="emphasis"><em>true</em></span>, the model packages will be |
| registered in the global registry. Otherwise, packages will |
| not be registered.</td></tr><tr><td align="left"><code class="varname">savePackagesPath</code></td><td align="left">Sets the path where model packages will be saved (in |
| XMI format).</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="Implementing Your Own Metamodel"><div class="titlepage"><div><div><h4 class="title"><a name="implementing_metamodels"></a>Implementing Your Own Metamodel</h4></div></div></div><a name="N109E5" class="indexterm"></a><p>The <span class="emphasis"><em>Xpand</em></span> framework also allows you to |
| integrate new metamodel implementations. This section quickly outlines |
| the steps that have to be taken in order to implement a |
| metamodel:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Create a class that implements the |
| <code class="classname">MetaModel</code> interface.</p></li><li class="listitem"><p>In order to be able to integrate your metamodel into the |
| Eclipse UI, you also have to provide a metamodel contributor class |
| for your metamodel implementation that implements either the |
| <code class="classname">MetaModelContributor</code> or the |
| <code class="classname">MetaModelContributor2</code> interface.</p></li><li class="listitem"><p>Finally, you have to extend the |
| <code class="classname">org.eclipse.xtend.shared.ui.metaModelContributors</code> |
| extension point in order to register your metamodel contributor |
| with the Eclipse UI.</p></li></ol></div></div></div></div><div class="section" title="Expressions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="r10_expressions_language"></a>Expressions<a name="N10A0A" class="indexterm"></a></h2></div></div></div><p>The expression sub-language<a name="N10A0F" class="indexterm"></a> is a syntactical mixture of Java and OCL<a name="N10A13" class="indexterm"></a>. This documentation provides a detailed description of each |
| available expression. Let us start with some simple examples.</p><p>Accessing a property:</p><pre class="programlisting">myModelElement.name</pre><p>Accessing an operation:</p><pre class="programlisting">myModelElement.doStuff()</pre><p>simple arithmetic:</p><pre class="programlisting">1 + 1 * 2</pre><p>boolean expressions (just an example:-)):</p><pre class="programlisting">!('text'.startsWith('t') && ! false)</pre><div class="section" title="Literals and special operators for built-in types"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_builtin"></a>Literals and special operators for built-in types</h3></div></div></div><p>There are several literals<a name="N10A2D" class="indexterm"></a> for built-in types:</p><div class="section" title="Object"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_object"></a><code class="classname">Object</code> <a name="N10A37" class="indexterm"></a> <a name="N10A3E" class="indexterm"></a></h4></div></div></div><p>There are naturally no literals for object, but we have two |
| operators:</p><p>equals:</p><pre class="programlisting">obj1 == obj2</pre><p>not equals:</p><pre class="programlisting">obj1 != obj2</pre></div><div class="section" title="Void"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_void"></a><code class="classname">Void</code></h4></div></div></div><p>The only possible instance of <code class="classname">Void</code> is the |
| <code class="varname">null</code> reference. Therefore, we have one |
| literal:</p><pre class="programlisting">null</pre></div><div class="section" title="Type literals"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_typeliterals"></a>Type literals</h4></div></div></div><p>The literal for types is just the name of the type (no |
| '<code class="filename">.class</code>' suffix, etc.). Example:</p><pre class="programlisting">String // the type string |
| my::special::Type // evaluates to the type 'my::special::Type'</pre></div><div class="section" title="StaticProperty literals"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_staticproperties"></a>StaticProperty literals</h4></div></div></div><p>The literal for static properties<a name="N10A6E" class="indexterm"></a> (aka enum literals<a name="N10A74" class="indexterm"></a>) is correlative to type literals:</p><pre class="programlisting">my::Color::RED</pre></div><div class="section" title="String"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_string"></a><code class="classname">String</code></h4></div></div></div><p>There are two different literal syntaxes (with the same |
| semantics):</p><pre class="programlisting">'a String literal' |
| "a String literal" // both are okay</pre><p>For Strings the expression sub-language supports the plus |
| operator that is overloaded with concatenation:</p><pre class="programlisting">'my element '+ ele.name +' is really cool!'</pre><p>Note, that multi-line Strings are supported.</p></div><div class="section" title="Boolean"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_boolean"></a><code class="classname">Boolean</code></h4></div></div></div><p>The boolean literals are:</p><pre class="programlisting">true |
| false</pre><p>Operators are:</p><pre class="programlisting">true && false // AND |
| true || false // OR |
| ! true // NOT</pre></div><div class="section" title="Integer and Real"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_numeric"></a><code class="classname">Integer</code> and |
| <code class="classname">Real</code></h4></div></div></div><p>The syntax for integer literals is as expected:</p><pre class="programlisting">// integer literals |
| 3 |
| 57278 |
| // real literals |
| 3.0 |
| 0.75</pre><p>Additionally, we have the common arithmetic operators:</p><pre class="programlisting">3 + 4 // addition |
| 4 - 5 // subtraction |
| 2 * 6 // multiplication |
| 3 / 64 // divide |
| // Unary minus operator |
| - 42 |
| - 47.11 |
| </pre><p>Furthermore, the well known compare operators are |
| defined:</p><pre class="programlisting">4 > 5 // greater than |
| 4 < 5 // smaller than |
| 4 >= 23 // greater equals than |
| 4 <= 12 // smaller equals than</pre></div><div class="section" title="Collections"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_builtin_collections"></a>Collections</h4></div></div></div><p>There is a literal for lists:</p><pre class="programlisting">{1,2,3,4} // a list with four integers</pre><p>There is no other special concrete syntax for collections. If |
| you need a set, you have to call the <code class="methodname">toSet()</code> |
| operation on the list literal:</p><pre class="programlisting">{1,2,4,4}.toSet() // a set with 3(!) integers</pre></div></div><div class="section" title="Special Collection operations"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_collection_operations"></a>Special Collection operations</h3></div></div></div><p>Like OCL, the <span class="emphasis"><em>Xpand</em></span> expression sub-language |
| defines several special operations on collections. However, those |
| operations are not members of the type system, therefore you cannot use |
| them in a reflective manner.</p><div class="section" title="select"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_select"></a><code class="methodname">select<a name="N10AC9" class="indexterm"></a></code></h4></div></div></div><p>Sometimes, an expression yields a large collection, but one is |
| only interested in a special subset of the collection. The expression |
| sub-language has special constructs to specify a selection out of a |
| specific collection. These are the <code class="methodname">select</code> and |
| <code class="methodname">reject</code> operations. The select specifies a |
| subset of a collection. A <code class="methodname">select</code> is an |
| operation on a collection and is specified as follows:</p><pre class="programlisting">collection.select(v | boolean-expression-with-v)</pre><p><code class="methodname">select</code> returns a sublist of the |
| specified collection. The list contains all elements for which the |
| evaluation of <code class="varname">boolean-expression-with-v</code> results is |
| <code class="varname">true</code>. Example:</p><pre class="programlisting">{1,2,3,4}.select(i | i >= 3) // returns {3,4}</pre></div><div class="section" title="typeSelect"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_typeselect"></a><code class="methodname">typeSelect</code> <a name="N10AEB" class="indexterm"></a></h4></div></div></div><p>A special version of a select expression is |
| <code class="methodname">typeSelect</code>. Rather than providing a boolean |
| expression a class name is here provided.</p><pre class="programlisting">collection.typeSelect(SomeType) </pre><p><code class="methodname">typeSelect</code> returns that sublist of the |
| specified collection, that contains only objects which are an instance |
| of the specified class (also inherited). It is equivalent to the |
| expression</p><pre class="programlisting">collection.select(e | SomeType.isInstance(e)) </pre></div><div class="section" title="reject"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_reject"></a><code class="methodname">reject<a name="N10B01" class="indexterm"></a></code></h4></div></div></div><p>The <code class="methodname">reject</code> operation is similar to the |
| <code class="methodname">select</code> operation, but with |
| <code class="methodname">reject</code> we get the subset of all the elements |
| of the collection for which the expression evaluates to |
| <code class="varname">false</code>. The <code class="methodname">reject</code> syntax |
| is identical to the <code class="methodname">select</code> syntax:</p><pre class="programlisting">collection.reject(v | boolean-expression-with-v)</pre><p>Example:</p><pre class="programlisting">{1,2,3,4}.reject(i | i >= 3) // returns {1,2}</pre></div><div class="section" title="collect"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_collect"></a><code class="methodname">collect<a name="N10B23" class="indexterm"></a></code></h4></div></div></div><p>As shown in the previous section, the |
| <code class="methodname">select</code> and <code class="methodname">reject</code> |
| operations always result in a sub-collection of the original |
| collection. Sometimes one wants to apply an operation on all elements |
| of the collection and collect the results of the evaluation in a list. |
| In such cases, we can use a <code class="methodname">collect</code> |
| operation. The <code class="methodname">collect</code> operation uses the |
| same syntax as the <code class="methodname">select</code> and |
| <code class="methodname">reject</code> and is written like this:</p><pre class="programlisting">collection.collect(v | expression-with-v)</pre><p><code class="methodname">collect</code> again iterates over the target |
| collection and evaluates the given expression on each element. In |
| contrast to <code class="methodname">select</code>, the evaluation result is |
| collected in a list. When an iteration is finished the list with all |
| results is returned. Example:</p><pre class="programlisting">namedElements.collect(ne | ne.name) // returns a list of strings |
| namedElements.collect(ne | ne.name.length > 3) // returns a list of boolean |
| </pre></div><div class="section" title="Shorthand for collect (and more than that)"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_collect_shorthand"></a>Shorthand for <code class="methodname">collect</code> (and more than |
| that)</h4></div></div></div><p>As navigation through many objects is very common, there is a |
| shorthand notation for collect <a name="N10B4E" class="indexterm"></a>that makes the expressions more readable. Instead |
| of</p><pre class="programlisting">self.employee.collect(e | e.birthdate) </pre><p>one can also write:</p><pre class="programlisting">self.employee.birthdate</pre><p>In general, when a property is applied to a collection of |
| Objects, it will automatically be interpreted as a |
| <code class="methodname">collect</code> over the members of the collection |
| with the specified property.</p><p>The syntax is a shorthand for <code class="methodname">collect</code>, |
| if the feature does not return a collection itself. But sometimes we |
| have the following:</p><pre class="programlisting">self.buildings.rooms.windows // returns a list of windows</pre><p>This syntax works, but one cannot express it using the |
| <code class="methodname">collect</code> operation in an easy way.</p></div><div class="section" title="forAll"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_forall"></a><code class="methodname">forAll</code></h4></div></div></div><p>Often a boolean expression has to be evaluated for all elements |
| in a collection. The <code class="methodname">forAll</code><a name="N10B72" class="indexterm"></a> operation allows specifying a Boolean expression, which |
| must be <code class="varname">true</code> for all objects in a collection in |
| order for the <code class="methodname">forAll</code> operation to return |
| <code class="varname">true</code>:</p><pre class="programlisting">collection.forAll(v | boolean-expression-with-v)</pre><p>The result of <code class="methodname">forAll</code> is |
| <code class="varname">true</code> if |
| <code class="varname">boolean-expression-with-v</code> is <code class="varname">true |
| </code>for all the elements contained in a collection. If |
| <code class="varname">boolean-expression-with-v</code> is |
| <code class="varname">false</code> for one or more of the elements in the |
| collection, then the <code class="methodname">forAll</code> expression |
| evaluates to <code class="varname">false</code>.</p><h5><a name="N10B9B"></a>Example:</h5><pre class="programlisting">{3,4,500}.forAll(i | i < 10) // evaluates to false (500 < 10 is false)</pre></div><div class="section" title="exists"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_exists"></a><code class="methodname">exists<a name="N10BA4" class="indexterm"></a></code></h4></div></div></div><p>Often you will need to know whether there is at least one |
| element in a collection for which a boolean is |
| <code class="varname">true</code>. The exists operation allows you to specify a |
| Boolean expression which must be <code class="varname">true</code> for at least |
| one object in a collection:</p><pre class="programlisting">collection.exists(v | boolean-expression-with-v)</pre><p>The result of the exists operation is <code class="varname">true</code> if |
| <code class="varname">boolean-expression-with-v</code> is |
| <code class="varname">true</code> for at least one element of collection. If the |
| <code class="varname">boolean-expression-with-v</code> is |
| <code class="varname">false</code> for all elements in collection, then the |
| complete expression evaluates to <code class="varname">false</code>.</p><h5><a name="N10BC5"></a>Example:</h5><pre class="programlisting">{3,4,500}.exists(i | i < 10) // evaluates to true (e.g. 3 < 10 is true)</pre></div><div class="section" title="sortBy"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_collection_sortby"></a><code class="methodname">sortBy</code></h4></div></div></div><p>If you want to sort a list of elements, you can use the higher |
| order function <code class="methodname">sortBy</code> <a name="N10BD3" class="indexterm"></a>. The list you invoke the |
| <code class="methodname">sortBy</code> operation on, is sorted by the results |
| of the given expression.</p><h5><a name="N10BDA"></a>Example:</h5><pre class="programlisting">myListOfEntity.sortBy(entity | entity.name)</pre><p>In the example the list of entities is sorted by the name of the |
| entities. Note that there is no such <code class="classname">Comparable</code> |
| type in <span class="emphasis"><em>Xpand</em></span>. If the values returned from the |
| expression are instances of |
| <code class="classname">java.util.Comparable</code> the |
| <code class="methodname">compareTo</code> method is used, otherwise |
| <code class="methodname">toString()</code> is invoked and the the result is |
| used.</p><p>All the following expressions return |
| <code class="varname">true</code>:</p><pre class="programlisting">{'C','B','A'}.sortBy(e | e) == {'A','B','C'} |
| {'AAA','BB','C'}.sortBy(e | e.length) == {'C','BB','AAA'} |
| {5,3,1,2}.sortBy(e | e) == {1,2,3,5} |
| {5,3,1,2}.sortBy(e | e - 2 * e) == {5,3,2,1} |
| ...</pre></div></div><div class="section" title="if expression"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_if"></a><code class="methodname">if</code> expression</h3></div></div></div><a name="N10BFC" class="indexterm"></a><p>There are two different forms of conditional expressions. The |
| first one is the so-called <span class="emphasis"><em>if expression</em></span>. |
| Syntax:</p><pre class="programlisting">condition ? thenExpression : elseExpression</pre><p><span class="bold"><strong>Example:</strong></span></p><pre class="programlisting">name != null ? name : 'unknown'</pre><p>Alternatively, you also could write:</p><pre class="programlisting">if name != null then |
| name |
| else |
| 'unknown' |
| </pre></div><div class="section" title="switch expression"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_switch"></a><code class="methodname">switch</code> expression</h3></div></div></div><a name="N10C18" class="indexterm"></a><p>The other one is called <span class="emphasis"><em>switch expression</em></span>. |
| Syntax:</p><pre class="programlisting">switch (expression) { |
| (case expression : thenExpression)* |
| default : catchAllExpression |
| }</pre><p>The default part is mandatory, because |
| <code class="methodname">switch</code> is an expression, therefore it needs to |
| evaluate to something in any case.</p><p><span class="bold"><strong>Example:</strong></span></p><pre class="programlisting">switch (person.name) { |
| case 'Hansen' : 'Du kanns platt schnacken' |
| default : 'Du kanns mi nech verstohn!' |
| }</pre><p>There is an abbreviation for <span class="emphasis"><em>Boolean</em></span> |
| expressions:</p><pre class="programlisting">switch { |
| case booleanExpression : thenExpression |
| default : catchAllExpression |
| } </pre></div><div class="section" title="Chain expression"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_chain"></a>Chain expression</h3></div></div></div><a name="N10C3A" class="indexterm"></a><p>Expressions and functional languages should be free of side |
| effects as far as possible. But sometimes there you need invocations |
| that do have side effects. In some cases expressions even do not have a |
| return type (i.e. the return type is <code class="classname">Void</code>). If |
| you need to call such operations, you can use the chain |
| expression.</p><p><span class="bold"><strong>Syntax:</strong></span></p><pre class="programlisting">anExpr -> |
| anotherExpr -> |
| lastExpr </pre><p>Each expression is evaluated in sequence, but only the result of |
| the last expression is returned.</p><p><span class="bold"><strong>Example</strong></span>:</p><pre class="programlisting">person.setName('test') -> |
| person</pre><p>This chain expression will set the <code class="varname">name</code> of the |
| person first, before it returns the person object itself.</p></div><div class="section" title="new expression"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_create"></a><code class="methodname">new</code> expression</h3></div></div></div><a name="N10C5E" class="indexterm"></a><p>The <code class="methodname">new</code> expression is used to instantiate |
| new objects of a given type:</p><pre class="programlisting">new TypeName</pre><p>Note that often <a class="link" href="#">create extensions</a> are |
| the better way to instantiate objects when used for model |
| transformations.</p></div><div class="section" title="'GLOBALVAR' expression"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_globalvar"></a>'GLOBALVAR' expression</h3></div></div></div><p>Sometimes you don't want to pass everything down the call stack by |
| parameter. Therefore, we have the <code class="methodname">GLOBALVAR</code> |
| <a name="N10C79" class="indexterm"></a> expression. There are two things you need to do, to use |
| global variables.</p><div class="section" title="Using GLOBALVARS to configure workflows"><div class="titlepage"><div><div><h4 class="title"><a name="r10_expressions_globalvar_workflow"></a>Using GLOBALVARS to configure workflows</h4></div></div></div><p>Each workflow component using the expression framework |
| (<span class="emphasis"><em>Xpand</em></span>, <span class="emphasis"><em>Check</em></span> and |
| <span class="emphasis"><em>Xtend</em></span>) can be configured with global variables. |
| <a name="N10C8C" class="indexterm"></a> Here is an example:</p><pre class="programlisting"><workflow> |
| .... stuff |
| <component class="org.eclipse.xpand2.Generator"> |
| ... usual stuff (see ref doc) |
| <globalVarDef name="MyPSM" value="slotNameOfPSM"/> |
| <globalVarDef name="ImplClassSuffix" value="'Impl'"/> |
| </component> |
| </workflow></pre><p>Note that <code class="varname">value</code> contains an expression or |
| slot name. If you want to pass a string value you will have to quote |
| the value, like the value for <code class="classname">ImplClassSuffix</code> |
| in the example.</p><p>If you have injected global variables into the respective |
| component, you can call them using the following syntax:</p><pre class="programlisting">GLOBALVAR ImplClassSuffix</pre><p>Note, we don't have any static type information. Therefore |
| <code class="classname">Object</code> is assumed. So, you have to down cast |
| the global variable to the intended type:</p><pre class="programlisting">((String) GLOBALVAR ImplClassSuffix)</pre><p>It is good practice to type it once, using an Extension and then |
| always refer to that extension:</p><pre class="programlisting">String implClassSuffix() : GLOBALVAR ImplClassSuffix; |
| // usage of the typed global var extension |
| ImplName(Class c) : |
| name+implClassSuffix();</pre></div></div><div class="section" title="Multi methods (multiple dispatch)"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_multidispatch"></a>Multi methods (multiple dispatch)</h3></div></div></div><p>The expressions language supports multiple dispatching <a name="N10CB1" class="indexterm"></a>. This means that when there is a bunch of overloaded |
| operations, the decision which operation has to be resolved is based on |
| the dynamic type of all parameters (the implicit |
| '<code class="varname">this</code>' included).</p><p>In Java only the dynamic type of the '<code class="varname">this</code>' |
| element is considered, for parameters the static type is used (this is |
| called single dispatch).</p><p>Here is a Java example:</p><pre class="programlisting">class MyType { |
| boolean equals(Object o) { |
| if (o instanceof MyClass) { |
| return equals((MyClass)o); |
| } |
| return super.equals(o); |
| } |
| boolean equals(MyType mt) { |
| //implementation... |
| } |
| } </pre><p>The method <code class="methodname">equals(Object o)</code> would not |
| have to be overwritten, if Java would support multiple dispatch.</p></div><div class="section" title="Casting"><div class="titlepage"><div><div><h3 class="title"><a name="r10_expressions_casting"></a>Casting<a name="N10CCB" class="indexterm"></a></h3></div></div></div><p>The expression language is statically type checked. Although there |
| are many concepts that help the programmer to have really good static |
| type information, sometimes. One knows more about the real type than the |
| system. To explicitly give the system such an information casts are |
| available. <span class="emphasis"><em>Casts are 100% static, so you do not need them, if |
| you never statically typecheck your expressions! </em></span></p><p>The syntax for casts is very Java-like:</p><pre class="programlisting">((String)unTypedList.get(0)).toUpperCase()</pre></div><div class="section" title="Xpand keywords and metamodel properties"><div class="titlepage"><div><div><h3 class="title"><a name="N10CD6"></a>Xpand keywords and metamodel properties<a name="N10CD9" class="indexterm"></a></h3></div></div></div><p>When the name of a metamodel property conflicts with an |
| <span class="emphasis"><em>Xpand</em></span> or <span class="emphasis"><em>Xtend</em></span> keyword, the |
| conflict is resolved in favour of the keyword. To refer to the metamodel |
| property in these cases, its name must be preceded by a |
| '<code class="varname">^</code>' character.</p><p>Example:</p><pre class="programlisting">private String foo(Import ^import) : ^import.name; |
| </pre></div></div><div class="section" title="Check"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Check_language"></a><span class="emphasis"><em>Check</em></span></h2></div></div></div><div class="section" title="Description of the Check language"><div class="titlepage"><div><div><h3 class="title"><a name="Check_language_description"></a>Description of the <span class="emphasis"><em>Check</em></span> language</h3></div></div></div><p><span class="emphasis"><em>Xpand</em></span> also provides a language to specify |
| constraints <a name="N10CFF" class="indexterm"></a> that the model has to fulfill in order to be correct. |
| This language is very easy to understand and use. Basically, it is built |
| around the expression syntax that has been discussed in detail in the |
| previous section. Constraints specified in the |
| <span class="emphasis"><em>Check</em></span> <a name="N10D06" class="indexterm"></a> language have to be stored in files with the file |
| extension <code class="filename">.chk</code> <a name="N10D0F" class="indexterm"></a><a name="N10D12" class="indexterm"></a>. Furthermore, these files have to be on the Java |
| classpath, of course, in order to be found. Let us look at an example, |
| in order to understand what these constraints look like and what they |
| do:</p><pre class="programlisting">import data; |
| context Attribute ERROR |
| "Names have to be more than one character long." : |
| name.length > 1;</pre><p>Now, let us look at the example line by |
| line:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>First, the metamodel has to be imported.</p></li><li class="listitem"><p>Then, the context is specified for which the constraint |
| applies. In other words, after the <code class="code">context</code> keyword, |
| we put the name of the metaclass that is going to be checked by |
| the constraint. Then, there follows either <code class="code">ERROR</code> or |
| <code class="code">WARNING</code>, These keywords specify what kind of action |
| will be taken in case the constraint fails:</p><div class="table"><a name="N10D2C"></a><p class="title"><b>Table 7. Types of action for <span class="emphasis"><em>Check</em></span> |
| constraints</b></p><div class="table-contents"><table summary="Types of action for Check |
| constraints" border="1"><colgroup><col><col></colgroup><tbody><tr><td><code class="code">WARNING</code></td><td>If the constraint fails, the specified message is |
| printed, but the workflow execution is not |
| stopped.</td></tr><tr><td><code class="code">ERROR</code></td><td>If the constraint fails, the specified message is |
| printed and all further processing is stopped.</td></tr></tbody></table></div></div><p><br class="table-break"></p></li><li class="listitem"><p>Now, the message that is put in case that the constraint |
| fails is specified as a string. It is possible to include the |
| value of attributes or the return value of functions into the |
| message in order to make the message more clear. For example, it |
| would be possible to improve the above example by rewriting it |
| like this:</p><pre class="programlisting">import data; |
| context Attribute ERROR |
| "Name of '" + name + "too short. Names have to be more than one character long." : |
| name.length > 1;</pre></li><li class="listitem"><p>Finally, there is the condition itself, which is specified |
| by an expression, which has been discussed in detail in the |
| previous section. If this expression is <code class="varname">true</code>, |
| the constraint is fulfilled.</p></li></ol></div><div class="important" title="Important" style="margin-left: 0.38in; margin-right: 0.38in;"><table border="0" summary="Important"><tr><td valign="top" align="center" rowspan="2" width="25"><img alt="[Important]" src="images/important.gif"></td><th align="left"></th></tr><tr><td valign="top" align="left"><p>Please always keep in mind that the message that is associated |
| with the constraint is printed, if the condition of the constraint |
| is <code class="varname">false</code>! Thus, if the specified constraint |
| condition is <code class="varname">true</code>, nothing will be printed out |
| and the constraint will be fulfilled.</p></td></tr></table></div><div class="section" title="Guard Conditions"><div class="titlepage"><div><div><h4 class="title"><a name="Guard_conditions"></a>Guard Conditions</h4></div></div></div><p>The <span class="emphasis"><em>Check</em></span> language of |
| <span class="emphasis"><em>Xpand</em></span> also provides so called <a name="N10D6A" class="indexterm"></a>. These conditions allow to apply a check constraint |
| only to model elements that meet certain criteria. Specifying such a |
| guard condition is done by adding an <span class="emphasis"><em>if</em></span> clause to |
| the check constraint. The <span class="emphasis"><em>if</em></span> clause has to be |
| added after the <span class="emphasis"><em>context</em></span> clause as demonstrated by |
| the following example: </p><pre class="programlisting">import data; |
| context Attribute if name.length > 1 ERROR |
| "Attribute names have to start with an 'a'" : |
| name.startsWith("a");</pre></div></div><div class="section" title="The workflow component CheckComponent"><div class="titlepage"><div><div><h3 class="title"><a name="check_checkcomponent"></a>The workflow component |
| <span class="emphasis"><em>CheckComponent</em></span></h3></div></div></div><p>The workflow component |
| <code class="classname">org.eclipse.xtend.check.CheckComponent</code> allows to |
| integrate model validation constraints using the |
| <span class="emphasis"><em>Check</em></span> into a modeling workflow using MWE.</p><p>This component provides the following configuration |
| properties:</p><div class="table"><a name="properties_checkcomponent"></a><p class="title"><b>Table 8. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Name of property</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"><code class="varname">checkFile</code></td><td align="left">This property allows to add files containing constraints |
| written in the <span class="emphasis"><em>Check</em></span> language to the |
| validation component.</td></tr><tr><td align="left"><code class="varname">emfAllChildrenSlot</code></td><td align="left">Name of a workflow slot that contains an EMF object, |
| which has to be validated including all child elements that it |
| contains. <span class="emphasis"><em>This property only works in conjunction with |
| EMF based models.</em></span></td></tr><tr><td align="left"><code class="varname">expression</code></td><td align="left">This property allows to set a check expression for the |
| validation component. <span class="strong"><strong>This property only |
| works in conjunction with non-EMF based |
| models.</strong></span></td></tr><tr><td align="left"><code class="varname">abortOnError</code></td><td align="left">This boolean property determines if the workflow will be |
| aborted or not if one of the validation constraints |
| fails.</td></tr><tr><td align="left"><code class="varname">warnIfNothingChecked</code></td><td align="left">If this boolean property will be set to |
| <span class="emphasis"><em>true</em></span>, a warning will be generated if there |
| were no validation checks. Otherwise, no warning will be |
| issued.</td></tr></tbody></table></div></div><br class="table-break"></div></div><div class="section" title="Xtend"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Xtend_language"></a><span class="emphasis"><em>Xtend</em></span></h2></div></div></div><a name="N10DCF" class="indexterm"></a><p>Like the expressions sublanguage that summarizes the syntax of |
| expressions for all the other textual languages delivered with the |
| <span class="emphasis"><em>Xpand</em></span> framework, there is another commonly used |
| language called <span class="emphasis"><em>Xtend</em></span>.</p><p>This language provides the possibility to define rich libraries of |
| independent operations and non-invasive metamodel extensions<a name="N10DDE" class="indexterm"></a> based on either Java methods or <span class="emphasis"><em>Xtend</em></span> |
| expressions. Those libraries can be referenced from all other textual |
| languages that are based on the expressions framework.</p><div class="section" title="Xtend files"><div class="titlepage"><div><div><h3 class="title"><a name="N10DE7"></a>Xtend files</h3></div></div></div><a name="N10DEA" class="indexterm"></a><p><a name="N10DEE" class="indexterm"></a>An Xtend file must reside in the Java class path of the |
| used execution context. File extension must be |
| <code class="filename">*.ext</code>. Let us have a look at an Xend file.</p><pre class="programlisting">import my::metamodel;extension other::ExtensionFile; |
| |
| /** |
| * Documentation |
| */ |
| anExpressionExtension(String stringParam) : |
| doingStuff(with(stringParam)) |
| ; |
| |
| /** |
| * java extensions are just mappings |
| */ |
| String aJavaExtension(String param) : JAVA |
| my.JavaClass.staticMethod(java.lang.String) |
| ; |
| </pre><p>The example shows the following statements:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>import statements</p></li><li class="listitem"><p>extension import statements</p></li><li class="listitem"><p>expression or java extensions</p></li></ol></div></div><div class="section" title="Comments"><div class="titlepage"><div><div><h3 class="title"><a name="N10E05"></a>Comments<a name="N10E08" class="indexterm"></a></h3></div></div></div><p>We have single- and multi-line comments. The syntax for single |
| line comments is:</p><pre class="programlisting">// my comment</pre><p>Multi line comments are written like this:</p><pre class="programlisting">/* My multi line comment */</pre></div><div class="section" title="Import Statements"><div class="titlepage"><div><div><h3 class="title"><a name="N10E15"></a>Import Statements</h3></div></div></div><p>Using the import<a name="N10E1A" class="indexterm"></a> statement one can import name spaces of different |
| types.(see expressions framework reference documentation).</p><p>Syntax is:</p><pre class="programlisting">import my::imported::namespace;</pre><p>Xtend does not support static imports or any similar concept. |
| Therefore, the following is incorrect syntax:</p><pre class="programlisting">import my::imported::namespace::*; // WRONG! import my::Type; // WRONG!</pre></div><div class="section" title="Extension Import Statement"><div class="titlepage"><div><div><h3 class="title"><a name="N10E26"></a>Extension Import Statement</h3></div></div></div><a name="N10E29" class="indexterm"></a><p>You can import another Xtend file using the extension statement. |
| The syntax is:</p><pre class="programlisting">extension fully::qualified::ExtensionFileName;</pre><p>Note, that no file extension (<code class="filename">*.ext</code>) is |
| specified.</p><div class="section" title="Reexporting Extensions"><div class="titlepage"><div><div><h4 class="title"><a name="N10E35"></a>Reexporting Extensions</h4></div></div></div><p>If you want to export extensions from another extension file |
| together with your local extensions, you can add the keyword |
| <code class="methodname">reexport</code> <a name="N10E3D" class="indexterm"></a> to the end of the respective extension import |
| statement.</p><pre class="programlisting">extension fully::qualified::ExtensionFileName reexport;</pre></div></div><div class="section" title="Extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N10E43"></a>Extensions</h3></div></div></div><p>The syntax of a simple expression extension is as follows:</p><pre class="programlisting">ReturnType extensionName(ParamType1 paramName1, ParamType2...): expression-using-params;</pre><p><span class="bold"><strong>Example:</strong></span></p><pre class="programlisting">String getterName(NamedElement ele) : 'get'+ele.name.firstUpper();</pre><div class="section" title="Extension Invocation"><div class="titlepage"><div><div><h4 class="title"><a name="N10E50"></a>Extension Invocation<a name="N10E53" class="indexterm"></a></h4></div></div></div><p>There are two different ways of how to invoke an extension. It |
| can be invoked like a function:</p><pre class="programlisting">getterName(myNamedElement)</pre><p>The other way to invoke an extension is through the "member |
| syntax":</p><pre class="programlisting">myNamedElement.getterName()</pre><p>For any invocation in member syntax, the target expression (the |
| member) is mapped to the first parameter. Therefore, both syntactical |
| forms do the same thing.</p><p>It is important to understand that extensions are not members of |
| the type system, hence, they are not accessible through reflection and |
| you cannot specialize or overwrite operations using them.</p><p>The expression evaluation engine first looks for an appropriate |
| operation before looking for an extension, in other words operations |
| have higher precedence.</p></div><div class="section" title="Type Inference"><div class="titlepage"><div><div><h4 class="title"><a name="N10E66"></a>Type Inference<a name="N10E69" class="indexterm"></a></h4></div></div></div><p>For most extensions, you do not need to specify the return |
| type,<a name="N10E6E" class="indexterm"></a> because it can be derived from the specified |
| expression. The special thing is, that the static return type of such |
| an extension depends on the context of use.</p><p>For instance, if you have the following extension</p><pre class="programlisting">asList(Object o): {o};</pre><p>the invocation of</p><pre class="programlisting">asList('text')</pre><p>has the static type <code class="classname">List[String]</code>. This |
| means you can call</p><pre class="programlisting">asList('text').get(0).toUpperCase()</pre><p>The expression is statically type safe, because its return type |
| is derived automatically.</p><p>There is <span class="emphasis"><em>always</em></span> a return value, whether you |
| specify it or not, even if you specify explicitly |
| '<code class="classname">Void</code>'.</p><p>See the following example.</p><pre class="programlisting">modelTarget.ownedElements.addAllNotNull(modelSource.contents.duplicate())</pre><p>In this example <code class="methodname">duplicate()</code> dispatches |
| polymorphically<a name="N10E94" class="indexterm"></a>. Two of the extensions might look like:</p><pre class="programlisting">Void duplicate(Realization realization): |
| realization.Specifier().duplicate()-> |
| realization.Realizer().duplicate() |
| ; |
| |
| create target::Class duplicate(source::Class): |
| ... |
| ;</pre><p>If a '<code class="classname">Realization</code>' is contained in the |
| '<code class="methodname">contents</code>' list of |
| '<code class="varname">modelSource</code>', the |
| '<code class="methodname">Realizer</code>' of the |
| '<code class="classname">Realization</code>' will be added to the |
| '<code class="varname">ownedElements</code>' list of the |
| '<code class="varname">modelTarget</code>'. If you do not want to add in the |
| case that the contained element is a 'Realization' you might change |
| the extension to:</p><pre class="programlisting">Void duplicate(Realization realization): |
| realization.Specifier().duplicate()-> |
| realization.Realizer().duplicate() -> |
| {} |
| ;</pre></div><div class="section" title="Recursion"><div class="titlepage"><div><div><h4 class="title"><a name="N10EB3"></a>Recursion</h4></div></div></div><p>There is only one exception: For recursive extensions <a name="N10EB8" class="indexterm"></a><a name="N10EBB" class="indexterm"></a> the return type cannot be inferred, therefore you need |
| to specify it explicitly:</p><pre class="programlisting">String fullyQualifiedName(NamedElement n) : n.parent == null ? n.name : |
| fullyQualifiedName(n.parent)+'::'+n.name |
| ;</pre><p>Recursive extensions are non-deterministic in a static context, |
| therefore, it is necessary to specify a return type.</p></div><div class="section" title="Cached Extensions"><div class="titlepage"><div><div><h4 class="title"><a name="N10EC5"></a>Cached Extensions<a name="N10EC8" class="indexterm"></a></h4></div></div></div><p>If you call an extension without side effects very often, you |
| would like to cache the result for each set of parameters, in order |
| improve the performance. You can just add the keyword |
| '<code class="code">cached</code>'<a name="N10ED2" class="indexterm"></a> to the extension in order to achieve this:</p><pre class="programlisting">cached String getterName(NamedElement ele) : |
| 'get'+ele.name.firstUpper() |
| ;</pre><p>The <code class="methodname">getterName</code> will be computed only |
| once for each <code class="classname">NamedElement</code>.</p></div><div class="section" title="Private Extensions"><div class="titlepage"><div><div><h4 class="title"><a name="N10EE0"></a>Private Extensions<a name="N10EE3" class="indexterm"></a></h4></div></div></div><p>By default all extensions are public, i.e. they are visible from |
| outside the extension file. If you want to hide extensions you can add |
| the keyword '<code class="methodname">private</code>'<a name="N10EED" class="indexterm"></a> in front of them:</p><pre class="programlisting">private internalHelper(NamedElement ele) : |
| // implementation.... |
| ;</pre></div></div><div class="section" title="Java Extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N10EF3"></a>Java Extensions</h3></div></div></div><p>In some cases one does want to call a Java method from inside an |
| expression. This can be done by providing a Java extension<a name="N10EF8" class="indexterm"></a><a name="N10EFB" class="indexterm"></a>:</p><pre class="programlisting">Void myJavaExtension(String param) : |
| JAVA my.Type.someMethod(java.lang.String) |
| ;</pre><p>The signature is the same as for any other extension. Its syntax |
| is:</p><pre class="programlisting">JAVA fully.qualified.Type.someMethod(my.ParamType1, |
| my.ParamType2, |
| ...) |
| ;</pre><p>Note that you cannot use any imported namespaces. You have to |
| specify the type, its method and the parameter types in a fully |
| qualified way.</p><p><span class="bold"><strong>Example:</strong></span></p><p>If you have defined the following Java extension:</p><pre class="programlisting">String concat (String a, String b): |
| JAVA my.Helper.concat(java.lang.String, java.lang.String);</pre><p>and you have the following Java class:</p><pre class="programlisting">package my; |
| |
| public class Helper { |
| public String concat(String a, String b){ |
| return a + b; |
| } |
| }</pre><p>the expressions</p><pre class="programlisting">concat('Hello ',"world!") |
| "Hello ".concat('world!')</pre><p>both result are invoking the Java method <code class="methodname">void |
| concat(String a, String b).</code></p><div class="section" title="static vs non-static invocation"><div class="titlepage"><div><div><h4 class="title"><a name="N10F1D"></a>static vs non-static invocation</h4></div></div></div><p>The implementation of a Java extension is redirected to a public |
| method in a Java class. If the method is not declared static it is |
| required that the Java class has a default constructor. Xtend will |
| instantiate the class for each invocation.</p></div><div class="section" title="IExecutionContextAware"><div class="titlepage"><div><div><h4 class="title"><a name="N10F22"></a>IExecutionContextAware<a name="N10F25" class="indexterm"></a></h4></div></div></div><p>It is possible with a Java Extension to gain access to the |
| ExecutionContext<a name="N10F2A" class="indexterm"></a>, which enables to retrieve detailed runtime information |
| on invocation. To use the current ExecutionContext in a Java extension |
| the class must implement |
| <code class="classname">org.eclipse.xtend.expression.IExecutionContextAware</code></p><pre class="programlisting">public interface IExecutionContextAware { |
| void setExecutionContext (ExecutionContext ctx); |
| } |
| </pre><p>The invoked method must not be static.</p></div></div><div class="section" title="Create Extensions (Model Transformation)"><div class="titlepage"><div><div><h3 class="title"><a name="create_extension"></a>Create Extensions (Model Transformation)</h3></div></div></div><p>The <span class="emphasis"><em>Xtend</em></span> language supports additional |
| support for model transformations<a name="N10F3E" class="indexterm"></a>. The concept is called <span class="emphasis"><em>create |
| extension</em></span> and <a name="N10F45" class="indexterm"></a><a name="N10F4A" class="indexterm"></a> it is explained a bit more comprehensive as usual.</p><p>Elements contained in a model are usually referenced multiple |
| times. Consider the following model structure:</p><pre class="programlisting"> P |
| / \ |
| C1 C2 |
| \ / |
| R |
| </pre><p>A package <code class="varname">P</code> contains two classes |
| <code class="varname">C1</code> and <code class="varname">C2</code>. <code class="varname">C1</code> |
| contains a reference <code class="varname">R</code> of type <code class="varname">C2</code> |
| (<code class="varname">P</code> also references <code class="varname">C2</code>).</p><p>We could write the following extensions in order to transform an |
| Ecore (EMF) model to our metamodel (Package, Class, Reference).</p><pre class="programlisting">Package toPackage(EPackage x) : |
| let p = new Package : |
| p.ownedMember.addAll(x.eClassifiers.toClass()) -> |
| p; |
| |
| Class toClass(EClass x) : |
| let c = new Class : |
| c.attributes.addAll(x.eReferences.toReference()) -> |
| c; |
| |
| Reference toReference(EReference x) : |
| let r = new Reference : |
| r.setType(x.eType.toClass()) -> |
| r; |
| </pre><p>For an Ecore model with the above structure, the result would |
| be:</p><pre class="programlisting"> P |
| / \ |
| C1 C2 |
| | |
| R - C2 |
| </pre><p>What happened? The <code class="varname">C2</code> class has been created 2 |
| times (one time for the package containment and another time for the |
| reference <code class="varname">R</code> that also refers to |
| <code class="varname">C2</code>). We can solve the problem by adding the |
| '<code class="methodname">cached</code>' keyword <a name="N10F82" class="indexterm"></a> to the second extension:</p><pre class="programlisting">cached toClass(EClass x) : |
| let c = new Class : |
| c.attributes.addAll(c.eAttributes.toAttribute()) -> |
| c; |
| </pre><p>The process goes like this:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>start create <code class="varname">P</code></p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>start create <code class="varname">C1</code> (contained in |
| <code class="varname">P</code>)</p><div class="orderedlist"><ol class="orderedlist" type="i"><li class="listitem"><p>start create <code class="varname">R</code> (contained in |
| <code class="varname">C1</code>)</p><div class="orderedlist"><ol class="orderedlist" type="A"><li class="listitem"><p>start create <code class="varname">C2</code> (referenced |
| from <code class="varname">R</code>)</p></li><li class="listitem"><p>end (result <code class="varname">C2</code> is |
| cached)</p></li></ol></div></li><li class="listitem"><p>end <code class="varname">R</code></p></li></ol></div></li><li class="listitem"><p>end <code class="varname">C1</code></p></li><li class="listitem"><p>start get cached <code class="varname">C2</code> (contained in |
| <code class="varname">P</code>)</p></li></ol></div></li><li class="listitem"><p>end P</p></li></ol></div><p>So this works very well. We will get the intended structure. But |
| what about circular dependencies? For instance, <code class="varname">C2</code> |
| could contain a <code class="classname">Reference</code> <code class="varname">R2</code> |
| of type <code class="varname">C1</code> (bidirectional references):</p><p>The transformation would occur like this:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>start create <code class="varname">P</code></p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>start create <code class="varname">C1</code> (contained in |
| <code class="varname">P</code>)</p><div class="orderedlist"><ol class="orderedlist" type="i"><li class="listitem"><p>start create <code class="varname">R</code> (contained in |
| <code class="varname">C1</code>)</p><div class="orderedlist"><ol class="orderedlist" type="A"><li class="listitem"><p>start create <code class="varname">C2</code> (referenced |
| from <code class="varname">R</code>)</p><div class="orderedlist"><ol class="orderedlist" type="I"><li class="listitem"><p>start create <code class="varname">R2</code> (contained |
| in <code class="varname">C2</code>)</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>start create <code class="varname">C1</code> (referenced |
| from <code class="varname">R1</code>)... OOPS!</p></li></ol></div></li></ol></div></li></ol></div></li></ol></div></li></ol></div></li></ol></div><p><code class="varname">C1</code> is already in creation and will not complete |
| until the stack is reduced. Deadlock! The problem is that the cache |
| caches the return value, but <code class="varname">C1</code> was not returned so |
| far, because it is still in construction.</p><p>The solution: create extensions!</p><p>The syntax is as follows:</p><pre class="programlisting">create Package toPackage(EPackage x) : |
| this.classifiers.addAll(x.eClassifiers.toClass()); |
| |
| create Class toClass(EClass x) : |
| this.attributes.addAll(x.eReferences.toReference()); |
| |
| create Reference toReference(EReference x) : |
| this.setType(x.eType.toClass()); |
| </pre><p>This is not only a shorter syntax, but it also has the needed |
| semantics: The created model element will be added to the cache before |
| evaluating the body. The return value is always the reference to the |
| created and maybe not completely initialized element.</p></div><div class="section" title="Calling Extensions From Java"><div class="titlepage"><div><div><h3 class="title"><a name="N11023"></a>Calling Extensions From Java</h3></div></div></div><p>The previous section showed how to implement Extensions in Java. |
| This section shows how to call Extensions from Java.<a name="N11028" class="indexterm"></a></p><pre class="programlisting">// setup |
| XtendFacade f = XtendFacade.create("my::path::MyExtensionFile"); |
| |
| // use |
| f.call("sayHello",new Object[]{"World"}); |
| </pre><p>The called extension file looks like this: <a name="N1102F" class="indexterm"></a></p><pre class="programlisting">sayHello(String s) : |
| "Hello " + s;</pre><p>This example uses only features of the |
| <code class="classname">BuiltinMetaModel</code>, in this case the |
| "<code class="methodname">+</code>" feature from the |
| <code class="classname">StringTypeImpl</code>.</p><p>Here is another example, that uses the |
| <code class="classname">JavaBeansMetaModel</code><a name="N11045" class="indexterm"></a> strategy. This strategy provides as additional feature: |
| the access to properties using the getter and setter methods.</p><p>For more information about type systems, see the <span class="emphasis"><em><a class="xref" href="#r10_expressions_language" title="Expressions">Expressions</a></em></span> reference |
| documentation.</p><p>We have one JavaBean-like metamodel class:</p><pre class="programlisting">package mypackage; |
| public class MyBeanMetaClass { |
| private String myProp; |
| public String getMyProp() { return myProp; } |
| public void setMyProp(String s) { myProp = s;} |
| }</pre><p>in addition to the built-in metamodel type system, we register the |
| <code class="classname">JavaMetaModel</code><a name="N11057" class="indexterm"></a> with the |
| <code class="classname">JavaBeansStrategy</code><a name="N1105D" class="indexterm"></a> for our facade. Now, we can use also this strategy in our |
| extension:</p><pre class="programlisting">// setup facade |
| |
| XtendFacade f = XtendFacade.create("myext::JavaBeanExtension"); |
| |
| // setup additional type system |
| JavaMetaModel jmm = |
| new JavaMetaModel("JavaMM", new JavaBeansStrategy()); |
| |
| f.registerMetaModel(jmm); |
| |
| // use the facade |
| MyBeanMetaClass jb = MyBeanMetaClass(); |
| jb.setMyProp("test"); |
| f.call("readMyProp", new Object[]{jb}));</pre><p>The called extension file looks like this:</p><pre class="programlisting">import mypackage; |
| |
| readMyProp(MyBeanMetaClass jb) : |
| jb.myProp |
| ; |
| </pre></div><div class="section" title="WorkflowComponent"><div class="titlepage"><div><div><h3 class="title"><a name="N11067"></a>WorkflowComponent<a name="N1106A" class="indexterm"></a></h3></div></div></div><p>With the additional support for model transformation, it makes |
| sense to invoke <span class="emphasis"><em>Xtend</em></span> within a workflow. A typical |
| workflow configuration of the <span class="emphasis"><em>Xtend</em></span> component |
| <a name="N11075" class="indexterm"></a>looks like this:</p><pre class="programlisting"><component class="org.eclipse.xtend.XtendComponent"> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelFile value="metamodel1.ecore"/> |
| </metamodel> |
| <metaModel class="org.eclipse.xtend.typesystem.type.emf.EmfMetaModel"> |
| <metaModelFile value="metamodel2.ecore"/> |
| </metaModel> |
| <invoke value="my::example::Trafo::transform(inputSlot)"/> |
| <outputSlot value="transformedModel"/> |
| </component> |
| </pre><p>Note that you can mix and use any kinds of metamodels (not only |
| EMF metamodels).</p></div><div class="section" title="Aspect-Oriented Programming in Xtend"><div class="titlepage"><div><div><h3 class="title"><a name="N1107E"></a>Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xtend</em></span><a name="N11083" class="indexterm"></a><a name="N11086" class="indexterm"></a></h3></div></div></div><p>Using the workflow engine, it is now possible to package (e.g. |
| zip) a written generator and deliver it as a kind of black box. If you |
| want to use such a generator but need to change some things without |
| modifying any code, you can make use of around advices that are |
| supported by <span class="emphasis"><em>Xtend</em></span>.</p><p>The following advice is weaved<a name="N11090" class="indexterm"></a> around every invocation of an extension whose name starts |
| with '<span class="package">my::generator::</span>':</p><pre class="programlisting">around my::generator::*(*) : |
| log('Invoking ' + ctx.name) -> ctx.proceed() |
| ; |
| </pre><p>Around advices<a name="N1109B" class="indexterm"></a> let you change behaviour in an non-invasive way (you do |
| not need to touch the packaged extensions).</p><div class="section" title="Join Point and Point Cut Syntax"><div class="titlepage"><div><div><h4 class="title"><a name="N1109F"></a>Join Point and Point Cut Syntax</h4></div></div></div><p>Aspect orientaton is basically about weaving code into different |
| points inside the call graph of a software module. Such points are |
| called <span class="emphasis"><em>join points</em></span>. In <span class="emphasis"><em>Xtend</em></span> |
| the join points are the extension invocations (Note that |
| <span class="emphasis"><em>Xpand</em></span> offers a similar feature, see the |
| <span class="emphasis"><em>Xpand</em></span> documentation).</p><p>One specifies on which join points <a name="N110B2" class="indexterm"></a> the contributed code should be executed by specifying |
| something like a 'query' on all available join points. Such a query is |
| called a point cut.<a name="N110B6" class="indexterm"></a></p><pre class="programlisting">around [pointcut] : |
| expression;</pre><p>A point cut consists of a fully qualified name and a list of |
| parameter declarations.</p><div class="section" title="Extensions Name"><div class="titlepage"><div><div><h5 class="title"><a name="N110BD"></a>Extensions Name</h5></div></div></div><p>The extension name part of a point cut must match the fully |
| qualified name of the definition of the join point. Such expressions |
| are case sensitive. The asterisk character is used to specify |
| wildcards.</p><p>Some examples:</p><pre class="programlisting">my::Extension::definition // extensions with the specified name |
| org::eclipse::xpand2::* //extensions prefixed with 'org::eclipse::xpand2::' |
| *Operation* // extensions containing the word 'Operation' in it. |
| * // all extensions</pre><div class="warning" title="Warning" style="margin-left: 0.38in; margin-right: 0.38in;"><table border="0" summary="Warning"><tr><td valign="top" align="center" rowspan="2" width="25"><img alt="[Warning]" src="images/warning.gif"></td><th align="left"></th></tr><tr><td valign="top" align="left"><p>Be careful when using wildcards, because you will get an |
| endless recursion, in case you weave an extension, which is called |
| inside the advice.</p></td></tr></table></div></div><div class="section" title="Parameter Types"><div class="titlepage"><div><div><h5 class="title"><a name="N110C9"></a>Parameter Types</h5></div></div></div><p>The parameters of the extensions that we want to add our |
| advice to, can also be specified in the point cut. The rule is, that |
| the type of the specified parameter must be the same or a supertype |
| of the corresponding parameter type (the dynamic type at runtime) of |
| the definition to be called.</p><p>Additionally, one can set the wildcard at the end of the |
| parameter list, to specify that there might be none or more |
| parameters of any kind.<a name="N110D0" class="indexterm"></a></p><p>Some examples:</p><pre class="programlisting">my::Templ::extension() // extension without parameters |
| my::Templ::extension(String s) // extension with exactly one parameter of type String |
| my::Templ::extension(String s,*) // templ def with one or more parameters, |
| // where the first parameter is of type String |
| my::Templ::extension(*) // templ def with any number of parameters |
| </pre></div><div class="section" title="Proceeding"><div class="titlepage"><div><div><h5 class="title"><a name="N110D9"></a>Proceeding</h5></div></div></div><p>Inside an advice, you might want to call the underlying |
| definition. This can be done using the implicit variable |
| <code class="varname">ctx</code>, which is of the type |
| <span class="type">xtend::AdviceContext</span><a name="N110E3" class="indexterm"></a> and provides an operation |
| <code class="methodname">proceed()</code><a name="N110E9" class="indexterm"></a> which invokes the underlying definition with the |
| original parameters (Note that you might have changed any mutable |
| object in the advice before).</p><p>If you want to control what parameters are to be passed to the |
| definition, you can use the operation |
| <code class="methodname">proceed(List[Object] params)</code>. You should be |
| aware, that in advices, no type checking is done.</p><p>Additionally, there are some inspection properties (like |
| <code class="varname">name</code>, <code class="varname">paramTypes</code>, etc.) |
| available.</p></div></div><div class="section" title="Workflow configuration"><div class="titlepage"><div><div><h4 class="title"><a name="N110FA"></a>Workflow configuration</h4></div></div></div><p>To weave the defined advices into the different join |
| points<a name="N110FF" class="indexterm"></a>, you need to configure the |
| <code class="classname">XtendComponent</code><a name="N11105" class="indexterm"></a> with the qualified names of the Extension files |
| containing the advices.</p><p>Example:</p><pre class="programlisting"><component class="org.eclipse.xtend.XtendComponent"> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelFile value="metamodel1.ecore"/> |
| </metamodel> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelFile value="metamodel2.ecore"/> |
| </metaModel> |
| |
| <invoke value="my::example::Trafo::transform(inputSlot)"/> |
| <outputSlot value="transformedModel"/> |
| <advices value="my::Advices,my::Advices2"/> |
| </component> |
| </pre></div><div class="section" title="Model-to-Model transformation with Xtend"><div class="titlepage"><div><div><h4 class="title"><a name="xtend_example_introduction"></a>Model-to-Model transformation with |
| <span class="emphasis"><em>Xtend</em></span></h4></div></div></div><p>This example uses Eclipse EMF as the basis <a name="N11118" class="indexterm"></a>for model-to-model transformations. It builds on the |
| <span class="emphasis"><em>emfExample</em></span> documented elsewhere. Please read and |
| install the <span class="emphasis"><em>emfExample</em></span> first.</p><p>The idea in this example is to transform the data model |
| introduced in the EMF example into itself. This might seem boring, but |
| the example is in fact quite illustrative.</p></div><div class="section" title="Workflow"><div class="titlepage"><div><div><h4 class="title"><a name="xtend_example_workflow"></a>Workflow</h4></div></div></div><p>By now, you should know the role and structure of workflow |
| files. Therefore, the interesting aspect of the workflow file below is |
| the <span class="emphasis"><em><code class="classname">XtendComponent</code></em></span>.</p><pre class="programlisting"><workflow> |
| <property file="workflow.properties"/> |
| ... |
| <component class="org.eclipse.xtend.XtendComponent"> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelPackage value="data.DataPackage"/> |
| </metaModel> |
| <invoke value="test::Trafo::duplicate(rootElement)"/> |
| <outputSlot value="newModel"/> |
| </component> |
| ... |
| </workflow></pre><p>As usual, we have to define the metamodel that should be used, |
| and since we want to transform a data model into a data model, we need |
| to specify only the <code class="classname">data.DataPackage</code> as the |
| metamodel.</p><p>We then specify which function to invoke for the transformation. |
| The statement |
| <code class="classname">test::Trafo::duplicate(rootElement)</code> means to |
| invoke: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>the <code class="classname">duplicate</code> function taking the |
| contents of the <code class="classname">rootElement</code> slot as a |
| parameter</p></li><li class="listitem"><p>the function can be found in the |
| <code class="filename">Trafo.ext</code> file</p></li><li class="listitem"><p>and that in turn is in the classpath, in the |
| <span class="package">test</span>package.</p></li></ul></div></div><div class="section" title="The transformation"><div class="titlepage"><div><div><h4 class="title"><a name="xtend_example_the_transformation"></a>The transformation</h4></div></div></div><p>The transformation, as mentioned above, can be found in the |
| <code class="filename">Trafo.ext</code> file in the <code class="classname">test</code> |
| package in the <code class="classname">src</code> folder. Let us walk through |
| the file.</p><p>So, first we import the metamodel.</p><pre class="programlisting">import data;</pre><p>The next function is a so-called create extension<a name="N11167" class="indexterm"></a><a name="N1116C" class="indexterm"></a>. Create extensions, as a side effect when called, |
| create an instance of the type given after the |
| <code class="classname">create</code> keyword. In our case, the |
| <code class="classname">duplicate</code> function creates an instance of |
| <code class="classname">DataModel</code>. This newly created object can be |
| referred to in the transformation <a name="N11179" class="indexterm"></a>by <code class="classname">this</code> (which is why |
| <code class="classname">this</code> is specified behind the type). Since |
| <code class="classname">this</code> can be omitted, we do not have to mention |
| it explicitly in the transformation.</p><p>The function also takes an instance of |
| <code class="classname">DataModel</code> as its only parameter. That object is |
| referred to in the transformation as <code class="varname">s</code>. So, this |
| function sets the name of the newly created |
| <code class="classname">DataModel</code> to be the name of the original one, |
| and then adds duplicates of all entities of the original one to the |
| new one. To create the duplicates of the entities, the |
| <code class="classname">duplicate()</code> operation is called for each |
| <code class="classname">Entity</code>. This is the next function in the |
| transformation.</p><pre class="programlisting">create DataModel this duplicate(DataModel s): |
| entity.addAll(s.entity.duplicate()) -> |
| setName(s.name);</pre><p>The duplication function for entities is also a create |
| extension. This time, it creates a new <code class="classname">Entity</code> |
| for each old <code class="classname">Entity</code> passed in. Again, it copies |
| the name and adds duplicates of the attributes and references to the |
| new one.</p><pre class="programlisting">create Entity this duplicate(Entity old): |
| attribute.addAll(old.attribute.duplicate()) -> |
| reference.addAll(old.reference.duplicate()) -> |
| setName(old.name);</pre><p>The function that copies the attribute is rather straight |
| forward, but ...</p><pre class="programlisting">create Attribute this duplicate(Attribute old): |
| setName(old.name) -> |
| setType(old.type);</pre><a name="N111AA" class="indexterm"></a><p>... the one for the references is more interesting. Note that a |
| reference, while being owned by some <code class="classname">Entity</code>, |
| also references another Entity as its target. So, how do you make sure |
| you do not duplicate the target twice? <span class="emphasis"><em>Xtend</em></span> |
| provides explicit support for this kind of situation. <span class="emphasis"><em>Create |
| extensions are only executed once per tuple of parameters!</em></span> |
| So if, for example, the <span class="emphasis"><em>Entity</em></span> behind the target |
| reference had already been duplicated by calling the |
| <code class="methodname">duplicate</code> function with the respective |
| parameter, the next time it will be called <span class="emphasis"><em>the exact same |
| object will be returned</em></span>. This is very useful for graph |
| transformations.</p><pre class="programlisting">create EntityReference this duplicate(EntityReference old): |
| setName( old.name ) -> |
| setTarget( old.target.duplicate() );</pre><p>For more information about the <span class="emphasis"><em>Xtend</em></span> |
| language please see the <span class="emphasis"><em><a class="xref" href="#Xtend_language" title="Xtend">Xtend</a></em></span> reference documentation.</p></div></div></div><div class="section" title="Xpand2"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand_reference_introduction"></a><span class="emphasis"><em>Xpand2</em></span></h2></div></div></div><p>The <span class="emphasis"><em>Xpand</em></span><a name="N111D8" class="indexterm"></a> language is used in templates to control the output |
| generation. This documentation describes the general syntax and semantics |
| of the <span class="emphasis"><em>Xpand</em></span> language.</p><p>Typing the <span class="foreignphrase"><em class="foreignphrase">guillemets</em></span><a name="N111E5" class="indexterm"></a> (« and ») used in the templates is supported by the Eclipse |
| editor, which provides keyboard shortcuts with <span class="keycap"><strong>Ctrl</strong></span>+<span class="keycap"><strong><</strong></span> and <span class="keycap"><strong>Ctrl</strong></span>+<span class="keycap"><strong>></strong></span>.</p><div class="section" title="Template files and encoding"><div class="titlepage"><div><div><h3 class="title"><a name="xpand_reference_template_files_and_ecoding"></a>Template files and encoding</h3></div></div></div><p>Templates are stored in files with the extension |
| <code class="filename">.xpt</code><a name="N111FF" class="indexterm"></a>.<a name="N11205" class="indexterm"></a> Template files<a name="N11209" class="indexterm"></a> must reside on the Java classpath of the generator |
| process.</p><p>Almost all characters used in the standard syntax are part of |
| <span class="emphasis"><em>ASCII</em></span> and should therefore be available in any |
| encoding<a name="N11214" class="indexterm"></a><a name="N11219" class="indexterm"></a>. The only limitation are the tag brackets |
| (<span class="emphasis"><em>guillemets</em></span>), for which the characters "«" (Unicode |
| <code class="varname">00AB</code>) and "»" (Unicode <code class="varname">00BB</code>) are |
| used. So for reading templates, an encoding should be used that supports |
| these characters (e.g. <code class="varname">ISO-8859-1</code> or |
| <code class="varname">UTF-8</code>).</p><p>Names of properties, templates, namespaces etc. must only contain |
| letters, numbers and underscores.</p></div><div class="section" title="General structure of template files"><div class="titlepage"><div><div><h3 class="title"><a name="xpand_reference_general_structure_of_template_files"></a>General structure of template files</h3></div></div></div><p>Here is a first example of a template:</p><pre class="programlisting">«IMPORT meta::model» |
| «EXTENSION my::ExtensionFile» |
| |
| «DEFINE javaClass FOR Entity» |
| «FILE fileName()» |
| package «javaPackage()»; |
| |
| public class «name» { |
| // implementation |
| } |
| «ENDFILE» |
| «ENDDEFINE»</pre><p>A template file consists of any number of IMPORT |
| statements, followed by any number of EXTENSION statements, followed by |
| one or more DEFINE blocks (called definitions).</p></div><div class="section" title="Statements of the Xpand language"><div class="titlepage"><div><div><h3 class="title"><a name="xpand_reference_statements_of_the_expand_language"></a>Statements of the <span class="emphasis"><em>Xpand</em></span> language</h3></div></div></div><div class="section" title="IMPORT"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_import"></a>IMPORT<a name="N11244" class="indexterm"></a></h4></div></div></div><p>If you are tired of always typing the fully qualified names of |
| your types and definitions, you can import a namespace using the |
| IMPORT statement. </p><pre class="programlisting">«IMPORT meta::model»</pre><p>This |
| one imports the namespace <code class="varname">meta::model</code>. If your |
| template contains such a statement, you can use the unqualified names |
| of all types and template files contained in that namespace. This is |
| similar to a Java import statement <code class="varname">import |
| meta.model.*</code>.</p></div><div class="section" title="EXTENSION"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_extension"></a>EXTENSION<a name="N11256" class="indexterm"></a></h4></div></div></div><p>Metamodels are typically described in a structural way |
| (graphical, or hierarchical, etc.) . A shortcoming of this is that it |
| is difficult to specify additional behaviour (query operations, |
| derived properties, etc.). Also, it is a good idea not to pollute the |
| metamodel with target platform specific information (e.g. Java type |
| names, packages, getter and setter names, etc.).</p><p>Extensions provide a flexible and convenient way of defining |
| additional features of metaclasses. You do this by using the <a class="link" href="#"><span class="emphasis"><em>Xtend</em></span><a name="N11261" class="indexterm"></a> language</a>.</p><p>An <code class="classname">EXTENSION</code> import points to the |
| <span class="emphasis"><em>Xtend</em></span> file containing the required extensions: |
| </p><pre class="programlisting">«EXTENSION my::ExtensionFile»</pre><p> Note |
| that extension files have to reside on the Java classpath<a name="N11271" class="indexterm"></a>, too. Therefore, they use the same namespace mechanism |
| (and syntax) as types and template files.</p></div><div class="section" title="DEFINE"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_define"></a>DEFINE<a name="N11279" class="indexterm"></a></h4></div></div></div><p>The central concept of <span class="emphasis"><em>Xpand</em></span> is the |
| <code class="code">DEFINE</code> block, also called a template. This is the |
| smallest identifiable unit in a template file<a name="N11284" class="indexterm"></a>. The tag consists of a name, an optional |
| comma-separated parameter list, as well as the name of the metamodel |
| class for which the template is defined. </p><pre class="programlisting">«DEFINE templateName(formalParameterList) FOR MetaClass» |
| a sequence of statements |
| «ENDDEFINE»</pre><p>To some extend, templates can be seen as special |
| methods of the metaclass. There is always an implicit |
| <code class="varname">this</code> parameter which can be used to address the |
| "underlying" model element; in our example above, this model element |
| is of type "<code class="classname">MetaClass</code>".</p><p>As in Java, a formal parameter list entry consists of the type |
| followed by the name of that parameter.</p><p>The body of a template can contain a sequence of other |
| statements including any text.</p><p>A full parametric polymorphism<a name="N11299" class="indexterm"></a> <a name="N1129D" class="indexterm"></a> is available for templates. If there are two templates |
| with the same name that are defined for two metaclasses which inherit |
| from the same superclass, <span class="emphasis"><em>Xpand</em></span> will use the |
| corresponding subclass template, in case the template is called for |
| the superclass. Vice versa, the template of the superclass would be |
| used in case a subclass template is not available. Note that this not |
| only works for the target type, but for all parameters. Technically, |
| the target type is handled as the first parameter.</p><p>So, let us assume you have the following metamodel: </p><div class="figure"><a name="N112A8"></a><p class="title"><b>Figure 1. Sample metamodel</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/XPand/metamodelexample.gif" alt="Sample metamodel"></div></div></div><p><br class="figure-break"></p><p>Assume further, you would have a model which contains a |
| collection of <code class="classname">A</code>, <code class="classname">B</code> and |
| <code class="classname">C</code> instances in the property |
| <code class="methodname">listOfAs</code>. Then, you can write the following |
| template: </p><pre class="programlisting">«DEFINE someOtherDefine FOR SomeMetaClass» |
| «EXPAND implClass FOREACH listOfAs» |
| «ENDDEFINE» |
| |
| «DEFINE implClass FOR A» |
| // this is the code generated for the superclass A |
| «ENDDEFINE» |
| |
| «DEFINE implClass FOR B» |
| // this is the code generated for the subclass B |
| «ENDDEFINE» |
| |
| «DEFINE implClass FOR C» |
| // this is the code generated for the subclass C |
| «ENDDEFINE»</pre><p>So for each <code class="classname">B</code> in the list, |
| the template defined for <code class="classname">B</code> is executed, for |
| each <code class="classname">C</code> in the collection the template defined |
| for <span class="emphasis"><em><code class="classname">C</code></em></span> is invoked, and for |
| all others (which are then instances of <code class="classname">A</code>) the |
| default template is executed.</p></div><div class="section" title="FILE"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_file"></a>FILE<a name="N112DA" class="indexterm"></a></h4></div></div></div><p>The <code class="varname">FILE</code> statement redirects the output |
| generated from its body statements to the specified target. |
| </p><pre class="programlisting">«FILE expression [outletName]» |
| a sequence of statements |
| «ENDFILE»</pre><p>The target is a file in the file system whose name |
| is specified by the expression (relative to the specified target |
| directory for that generator run). The expression for the target |
| specification can be a concatenation (using the + operator). |
| Additionally, you can specify an identifier (a legal Java identifier) |
| for the name of the outlet<a name="N112E5" class="indexterm"></a>. (See the configuration section for a description of |
| outlets). To produce the target file into subdirectories use "/" in |
| the expression result as separator for the directory structure.</p><p>The body of a <code class="varname">FILE</code> statement can contain any |
| other statements.</p><p><span class="bold"><strong>Example: </strong></span></p><pre class="programlisting">«FILE InterfaceName + ".java"» |
| package «InterfacePackageName»; |
| |
| /* generated class! Do not modify! */ |
| public interface «InterfaceName» { |
| «EXPAND Operation::InterfaceImplementation FOREACH Operation» |
| } |
| «ENDFILE» |
| |
| |
| «FILE ImplName + ".java" MY_OUTLET» |
| package «ImplPackageName»; |
| |
| public class «ImplName» extends «ImplBaseName» |
| implements «InterfaceName» { |
| //TODO: implement it |
| } |
| «ENDFILE»</pre></div><div class="section" title="EXPAND"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_expand"></a>EXPAND<a name="N112F8" class="indexterm"></a></h4></div></div></div><p>The <code class="varname">EXPAND</code> statement "expands" another |
| <code class="varname">DEFINE</code> block (in a separate variable context), |
| inserts its output at the current location and continues with the next |
| statement. This is similar in concept to a subroutine call. |
| </p><pre class="programlisting">«EXPAND definitionName [(parameterList)] |
| [FOR expression | FOREACH expression [SEPARATOR expression] ] [ONFILECLOSE]»</pre><p>The |
| various alternative syntaxes are explained below.</p><div class="section" title="Names"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_names"></a>Names</h5></div></div></div><p>If the <span class="emphasis"><em>definitionName</em></span> is a simple |
| unqualified name, the corresponding <code class="varname">DEFINE</code> block |
| must be in the same template file.</p><p>If the called definition is not contained in the same template |
| file, the name of the template file must be specified. As usual, the |
| double colon is used to delimit namespaces. </p><pre class="programlisting">«EXPAND TemplateFile::definitionName FOR myModelElement»</pre><p>Note |
| that you would need to import the namespace<a name="N11317" class="indexterm"></a> of the template file (if there is one). For instance, |
| if the template file resides in the java package |
| <code class="varname">my.templates</code>, there are two alternatives. You |
| could either write </p><pre class="programlisting">«IMPORT my::templates» |
| ... |
| «EXPAND TemplateFile::definitionName FOR myModelElement»</pre><p> or |
| </p><pre class="programlisting">«EXPAND my::templates::TemplateFile::definitionName |
| FOR myModelElement»</pre></div><div class="section" title="Lazy evaluation"><div class="titlepage"><div><div><h5 class="title"><a name="N11325"></a>Lazy evaluation</h5></div></div></div><p>Appending the <a name="N1132A" class="indexterm"></a><code class="classname">ONFILECLOSE</code> statement defers |
| evaluation of the expanded definition until the current file is |
| closed with <code class="classname">ENDFILE</code>. This is of use when the |
| state required to create the text is collected during the evaluation |
| of the processed definition.</p><pre class="programlisting">«FILE ...» |
| ... |
| «EXPAND LazyEvaluatedDefinition FOREACH myCollection ONFILECLOSE» |
| ... |
| «ENDFILE» «REM»Now 'LazyEvaluatedDefinition' is called«ENDFILE»</pre><p>A typical example for usage of the |
| <code class="classname">ONFILECLOSE</code> statement is when you want to |
| create a list of imports in a Java class, but the types that are |
| used should be added when they are used in the templates |
| later.</p><p>The state, usually a collection, that is used for the lazy |
| expanded evaluation must be valid until the file is closed. This can |
| be achieved in two ways:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Span a <code class="classname">LET</code> statement around the |
| <code class="classname">FILE</code> statement that bounds an empty |
| collection</p><pre class="programlisting">«LET (List[MyType]) {} AS importedTypes» |
| «FILE ...» |
| ... |
| «EXPAND ImportStatement FOREACH importedTypes ONFILECLOSE» |
| ... |
| «importedTypes.add(someType) -> ""-» |
| ... |
| «ENDFILE» |
| «ENDLET»</pre></li><li class="listitem"><p>Use a <a class="link" href="#create_extension" title="Create Extensions (Model Transformation)"><span class="emphasis"><em>create |
| extension</em></span></a> which returns an empty collection |
| and append elements to it. Since it is a create extension the |
| empty collection will be returned on first call and for each |
| subsequent call a reference to this collection will be returned |
| and not a new collection created.</p><p><span class="bold"><strong>Example:</strong></span></p><p><code class="filename">some/path/InsertionPoints.ext</code>:</p><pre class="programlisting">create List[Type] importedTypes (SomeType context) : (List[Type]) {}; </pre><p>In Xpand use this as follows:</p><pre class="programlisting">«EXTENSION some::path::InsertionPoints» |
| «FILE ...» |
| ... |
| «EXPAND ImportStatement FOREACH importedTypes() ONFILECLOSE» |
| ... |
| «importedTypes().add(someType) -> ""-» |
| ... |
| «ENDFILE» |
| «ENDLET»</pre></li></ul></div></div></div><div class="section" title="FOR vs. FOREACH"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_for_vs_foreach"></a>FOR vs. FOREACH<a name="N11365" class="indexterm"></a><a name="N11368" class="indexterm"></a></h4></div></div></div><p>If <code class="varname">FOR</code> or <code class="varname">FOREACH</code> is |
| omitted the other template is called <code class="varname">FOR this</code>. |
| </p><pre class="programlisting">«EXPAND TemplateFile::definitionName»</pre><p> |
| equals </p><pre class="programlisting">«EXPAND TemplateFile::definitionName FOR this»</pre><p> |
| If <code class="varname">FOR</code> is specified, the definition is executed for |
| the result of the target expression. </p><pre class="programlisting">«EXPAND myDef FOR entity»</pre><p>If |
| <code class="varname">FOREACH</code> is specified, the target expression must |
| evaluate to a collection type<a name="N11385" class="indexterm"></a>. In this case, the specified definition is executed for |
| each element of that collection. </p><pre class="programlisting">«EXPAND myDef FOREACH entity.allAttributes» </pre><p>An <code class="varname">EvaluationException</code> will be thrown if the |
| specified target expression cannot be evaluated to an existing element |
| of the instantiated model or no suitable <code class="varname">DEFINE</code> |
| block can be found.</p><div class="section" title="Specifying a Separator"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_specifying_a_separator"></a>Specifying a Separator<a name="N11397" class="indexterm"></a></h5></div></div></div><p>If a definition is to be expanded <code class="varname">FOREACH</code> |
| element of the target expression it is possible to specify a |
| <code class="varname">SEPARATOR</code> expression: </p><pre class="programlisting">«EXPAND paramTypeAndName FOREACH params SEPARATOR ','»</pre><p>The |
| result of the separator expression<a name="N113A5" class="indexterm"></a> will be written to the output between each evaluation |
| of the target definition. Not <span class="emphasis"><em>after</em></span> each one, |
| but rather only in <span class="emphasis"><em>between</em></span> two elements. This |
| comes in handy for things such as comma-separated parameter |
| lists.</p></div></div><div class="section" title="FOREACH"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_foreach"></a>FOREACH</h4></div></div></div><p>This statement expands the body of the |
| <code class="varname">FOREACH</code> block for each element of the target |
| collection<a name="N113BA" class="indexterm"></a> that results from the expression. The current element |
| is bound to a variable with the specified name in the current context. |
| </p><pre class="programlisting">«FOREACH expression AS variableName [ITERATOR iterName] [SEPARATOR expression]» |
| a sequence of statements using variableName to access the |
| current element of the iteration |
| «ENDFOREACH»</pre><p>The body of a <code class="varname">FOREACH</code> block |
| can contain any other statements; specifically |
| <code class="varname">FOREACH</code> statements may be nested.</p><p>If <code class="varname">ITERATOR</code><a name="N113CB" class="indexterm"></a> name is specified, an object of the type |
| <code class="classname">xpand2::Iterator</code> (see API doc for details) is |
| accessible using the specified name.</p><p>The <code class="varname">SEPARATOR</code> expression works in the same |
| way as the one for <a class="link" href="#xpand_reference_specifying_a_separator" title="Specifying a Separator"><code class="varname">EXPAND</code></a>.</p><p><span class="bold"><strong>Example: </strong></span></p><pre class="programlisting">«FOREACH {'A','B','C'} AS c ITERATOR iter SEPARATOR ','» |
| «iter.counter1» : «c» |
| «ENDFOREACH»</pre><p>The evaluation of the above statement results in |
| the following text: </p><pre class="programlisting">1 : A, |
| 2 : B, |
| 3 : C</pre></div><div class="section" title="IF"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_if"></a>IF<a name="N113E9" class="indexterm"></a></h4></div></div></div><p>The <code class="varname">IF</code> statement supports conditional |
| expansion. Any number of <code class="varname">ELSEIF</code><a name="N113F3" class="indexterm"></a> statements is allowed. The <code class="varname">ELSE</code> |
| block is optional. Every <code class="varname">IF</code> statement must be |
| closed with an <code class="varname">ENDIF</code><a name="N113FF" class="indexterm"></a>. The body of an <code class="varname">IF</code> block can contain |
| any other statement, specifically, <code class="varname">IF</code> statements |
| may be nested. </p><pre class="programlisting">«IF expression» |
| a sequence of statements |
| [ «ELSEIF expression» ] |
| a sequence of statements ] |
| [ «ELSE» |
| a sequence of statements ] |
| «ENDIF»</pre></div><div class="section" title="PROTECT"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_protect"></a>PROTECT<a name="N1140F" class="indexterm"></a></h4></div></div></div><p>Protected Regions<a name="N11414" class="indexterm"></a> are used to mark sections in the generated code that |
| shall not be overridden again by the subsequent generator run. These |
| sections typically contain manually written code. </p><pre class="programlisting">«PROTECT CSTART expression CEND expression ID expression (DISABLE)?» |
| a sequence of statements |
| «ENDPROTECT»</pre><p>The values of |
| <code class="classname">CSTART</code><a name="N1141D" class="indexterm"></a> and <code class="classname">CEND</code><a name="N11423" class="indexterm"></a> expressions are used to enclose the protected regions |
| marker in the output. They should build valid comment beginning and |
| comment end strings corresponding to the generated target language |
| (e.g. <span class="emphasis"><em>"/*"</em></span> and <span class="emphasis"><em>"*/"</em></span> for |
| Java).</p><p>The following is an example for Java: </p><pre class="programlisting">«PROTECT CSTART "/*" CEND "*/" ID ElementsUniqueID» |
| here goes some content |
| «ENDPROTECT»</pre><p>The ID is set by the <code class="varname">ID</code> |
| expression and must be <span class="emphasis"><em>globally unique</em></span> (at least |
| for one complete pass of the generator). To assure this these IDs are |
| usually concatenated. Some model types (e.g. UML2 models) contain |
| identifiers that could be used, which can be read using the <a class="link" href="#stdlib_uid_xmlid" title="String xmlId (ecore::EObject o)"><code class="methodname">xmlId()</code> function |
| from stdlib</a>.</p><p>Generated target code looks like this: </p><pre class="programlisting">public class Person { |
| /*PROTECTED REGION ID(Person) ENABLED START*/ |
| This protected region is enabled, therefore the contents will |
| always be preserved. If you want to get the default contents |
| from the template you must remove the ENABLED keyword (or even |
| remove the whole file :-)) |
| /*PROTECTED REGION END*/ |
| }</pre><p>Protected regions are generated in enabled state<a name="N11443" class="indexterm"></a> by default. Unless you manually disable<a name="N11449" class="indexterm"></a> them, by removing the <code class="varname">ENABLED</code> |
| keyword, they will always be preserved.</p><p>If you want the generator to generate disabled protected |
| regions, you need to add the <code class="varname">DISABLE</code> keyword inside |
| the declaration: </p><pre class="programlisting">«PROTECT CSTART '/*' CEND '*/' ID this.name DISABLE»</pre><p>The produced target code won't contain the |
| <code class="classname">ENABLED</code> flag then. In this case |
| <code class="classname">ENABLED</code> has to be added to the target region to |
| activate the protected region. Disabling protected regions by default |
| has the advantage that the protected region default content in the |
| template can be changed and all not yet activated regions would |
| contain the changed code after regeneration.</p></div><div class="section" title="LET"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_let"></a>LET<a name="N11465" class="indexterm"></a></h4></div></div></div><p><code class="varname">LET</code> lets you specify local |
| variables:</p><pre class="programlisting">«LET expression AS variableName» |
| a sequence of statements |
| «ENDLET»</pre><p>During the expansion of the body of the |
| <code class="varname">LET</code><a name="N11471" class="indexterm"></a> block, the value of the expression is bound to the |
| specified variable. Note that the expression will only be evaluated |
| once, independent from the number of usages of the variable within the |
| <code class="varname">LET</code> block.</p><p><span class="bold"><strong>Example:</strong></span> </p><pre class="programlisting">«LET packageName + "." + className AS fqn» |
| the fully qualified name is: «fqn»; |
| «ENDLET»</pre><p>The variable value can not be reassigned within a |
| <code class="classname">LET</code> block.</p></div><div class="section" title="ERROR"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_error"></a>ERROR<a name="N11488" class="indexterm"></a></h4></div></div></div><p>The <code class="varname">ERROR</code> statement aborts the evaluation of |
| the templates by throwing an |
| <code class="varname">XpandException</code><a name="N11492" class="indexterm"></a> with the specified message. </p><pre class="programlisting">«ERROR expression»</pre><p>Note |
| that you should use this facility very sparingly, since it is better |
| practice to check for invalid models using constraints on the |
| metamodel, and not in the templates!</p></div><div class="section" title="Comments"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_comments"></a>Comments<a name="N1149D" class="indexterm"></a></h4></div></div></div><p>Comments are only allowed outside of tags. </p><pre class="programlisting">«REM» |
| text comment |
| «ENDREM»</pre><p>Comments may not contain a REM<a name="N114A7" class="indexterm"></a> tag, this implies that comments are not nestable. A |
| comment may not have a white space between the |
| <code class="classname">REM</code> keyword and its brackets.</p><p><span class="bold"><strong>Example:</strong></span> </p><pre class="programlisting">«REM»«LET expression AS variableName»«ENDREM» |
| a sequence of statements |
| «REM» «variableName.stuff» |
| «ENDLET»«ENDREM»</pre></div><div class="section" title="Expression Statement"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_expression_statement"></a>Expression Statement<a name="N114B9" class="indexterm"></a></h4></div></div></div><p>Expressions support processing of the information provided by |
| the instantiated metamodel. <span class="emphasis"><em>Xpand</em></span> provides |
| powerful expressions for selection, aggregation, and navigation. |
| <span class="emphasis"><em>Xpand</em></span> uses the expressions sublanguage in almost |
| any statement that we have seen so far. The expression statement just |
| evaluates the contained expression and writes the result to the output |
| (using the <code class="varname">toString()</code> method of |
| <code class="varname">java.lang.Object</code>). Example: </p><pre class="programlisting">public class «this.name» {</pre><p>All |
| expressions defined by the expressions sublanguage are also available |
| in <span class="emphasis"><em>Xpand</em></span>. You can invoke imported extensions. |
| (See the <span class="emphasis"><em><a class="xref" href="#r10_expressions_language" title="Expressions">Expressions</a></em></span> and <span class="emphasis"><em><a class="xref" href="#Xtend_language" title="Xtend">Xtend</a> language reference</em></span> for more |
| details).</p></div><div class="section" title="Controlling generation of whitespace"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_controlling_generation_of_white_space"></a>Controlling generation of whitespace</h4></div></div></div><p>If you want to omit the output of superfluous |
| whitespace<a name="N114E1" class="indexterm"></a> you can add a minus sign just before any closing |
| bracket.</p><p><span class="bold"><strong>Example:</strong></span> </p><pre class="programlisting">«FILE InterfaceName + ".java"-» |
| «IF hasPackage-» |
| package «InterfacePackageName»; |
| «ENDIF-» |
| ... |
| «ENDFILE»</pre><p>The generated file would start with two new lines |
| (one after the <code class="varname">FILE</code> and one after the |
| <code class="varname">IF</code> statement) if the minus characters had not been |
| set.</p><p>In general, this mechanism works as follows: If a statement (or |
| comment) ends with such a minus all preceding whitespace up to the |
| newline<a name="N114F7" class="indexterm"></a> character (excluded!) is removed. Additionally all |
| following whitespace including the first newline character |
| (<code class="varname">\r\n</code> is handled as one character) is also |
| removed.</p></div></div><div class="section" title="Aspect-Oriented Programming in Xpand"><div class="titlepage"><div><div><h3 class="title"><a name="xpand_reference_aspect-oriented_programming_in_xpand"></a>Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xpand</em></span><a name="N11504" class="indexterm"></a></h3></div></div></div><p>Using the workflow engine it is now possible to package |
| (<span class="emphasis"><em>e.g.</em></span> zip) a written generator and deliver it as a |
| kind of black box (this is often called a cartridge<a name="N1150C" class="indexterm"></a>). If you want to use such a generator but need to change |
| some small generation stuff, you can make use of the |
| <code class="varname">AROUND</code><a name="N11512" class="indexterm"></a> aspects. </p><pre class="programlisting">«AROUND qualifiedDefinitionName(parameterList)? FOR type» |
| a sequence of statements |
| «ENDAROUND» </pre><p><code class="varname">AROUND</code> lets you add templates |
| in an non-invasive way (you do not need to touch the generator |
| templates). Because aspects are invasive, a template file containing |
| <code class="varname">AROUND</code> aspects must be wrapped by configuration (see |
| next section).</p><div class="section" title="Join Point and Point Cut Syntax"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_join_point_and_cut_syntax"></a>Join Point<a name="N11522" class="indexterm"></a><a name="N11525" class="indexterm"></a> and Point Cut<a name="N1152B" class="indexterm"></a><a name="N1152E" class="indexterm"></a> Syntax</h4></div></div></div><p>AOP is basically about weaving code into different points inside |
| the call graph of a software module. Such points are called |
| <span class="emphasis"><em>Join Points</em></span><a name="N11538" class="indexterm"></a>. In <span class="emphasis"><em>Xpand</em></span>, there is only one join |
| point so far: a call to a definition.</p><p>You specify on which join points the contributed code should be |
| executed by specifying something like a 'query' on all available join |
| points. Such a query is called a <span class="emphasis"><em>point |
| cut</em></span><a name="N11543" class="indexterm"></a>. </p><pre class="programlisting">«AROUND [pointcut]» |
| do stuff |
| «ENDAROUND»</pre><p> A point cut consists of a fully qualified name, |
| parameter types and the target type.</p><div class="section" title="Definition Name"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_definition_name"></a>Definition Name</h5></div></div></div><p>The definition name part of a point cut must match the fully |
| qualified name of the join point definition. Such expressions are |
| <span class="emphasis"><em>case sensitive</em></span>. The asterisk character is used |
| to specify wildcards.</p><p>Some examples: </p><pre class="programlisting">my::Template::definition // definitions with the specified name |
| org::eclipse::xpand2::* // definitions prefixed with 'org::eclipse::xpand2::' |
| *Operation* // definitions containing the word 'Operation' in it. |
| * // all definitions</pre></div><div class="section" title="Parameter Types"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_parameter_types"></a>Parameter Types</h5></div></div></div><p>The parameters of the definitions we want to add our advice |
| to, can also be specified in the point cut. The rule is that the |
| type of the specified parameter must be the same or a supertype of |
| the corresponding parameter type (the dynamic type at runtime!) of |
| the definition to be called.</p><p>Additionally, one can set a wildcard at the end of the |
| parameter list, to specify that there might be an arbitrary number |
| of parameters of any kind.</p><p>Some examples: </p><pre class="programlisting">my::Templ::def() // templ def without parameters |
| my::Templ::def(String s) // templ def with exactly one parameter |
| // of type String |
| my::Templ::def(String s,*) // templ def with one or more parameters, |
| // where the first parameter is of type String |
| my::Templ::def(*) // templ def with any number of parameters</pre></div><div class="section" title="Target Type"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_target_type"></a>Target Type</h5></div></div></div><p>Finally, we have to specify the target type. This is |
| straightforward: </p><pre class="programlisting">my::Templ::def() FOR Object// templ def for any target type |
| my::Templ::def() FOR Entity// templ def objects of type Entity</pre></div></div><div class="section" title="Proceeding"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_proceeding"></a>Proceeding</h4></div></div></div><p>Inside an advice, you might want to call the underlying |
| definition. This can be done using the implicit variable |
| <code class="varname">targetDef</code>, which is of the type |
| <span class="type">xpand2::Definition</span> and which provides an operation |
| <code class="methodname">proceed()</code>that invokes the underlying |
| definition with the original parameters (Note that you might have |
| changed any mutable object in the advice before).</p><p>If you want to control which parameters are to be passed to the |
| definition, you can use the operation <code class="methodname">proceed</code> |
| (<code class="classname">Object</code> <code class="varname">target</code>, |
| <code class="classname">List</code> <code class="varname">params</code>). Please keep in |
| mind that no type checking is done in this context.</p><p>Additionally, there are some inspection properties (like |
| <code class="varname">name</code>, <code class="varname">paramTypes</code>, etc.) |
| available.</p></div></div><div class="section" title="Generator Workflow Component"><div class="titlepage"><div><div><h3 class="title"><a name="xpand_reference_generator_workflow_component"></a>Generator Workflow Component<a name="N11597" class="indexterm"></a></h3></div></div></div><p>This section describes the workflow component that is provided to |
| perform the code generation, i.e. run the templates. You should have a |
| basic idea of how the workflow engine works. A simple generator |
| component configuration could look as follows:</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| <fileEncoding value="ISO-8859-1"/> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfMetaModel"> |
| <metaModelPackage value="org.eclipse.emf.ecore.EcorePackage"/> |
| </metaModel> |
| <expand value="somenamespace::example::Java::all FOR myModel"/> |
| |
| <!-- aop configuration --> |
| <advices value='somenamespace::example::Advices1, example::Advices2'/> |
| |
| <!-- output configuration --> |
| <outlet path='main/src-gen'> |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| <postprocessor class="org.eclipse.xtend.typesystem.xsd.XMLBeautifier"/> |
| </outlet> |
| <outlet name='TO_SRC' path='main/src' overwrite='false'> |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| <postprocessor class="org.eclipse.xtend.typesystem.xsd.XMLBeautifier"/> |
| </outlet> |
| |
| <!-- optional: protected regions configuration --> |
| <prSrcPaths value="main/src"/> |
| <prDefaultExcludes value="false"/> |
| <prExcludes value="*.xml"/> |
| </component></pre><p>Now, let us go through the different |
| properties one by one.</p><div class="section" title="Main configuration"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_main_configuration"></a>Main configuration</h4></div></div></div><p>The first thing to note is that the qualified Java name of the |
| component is <code class="varname">org.eclipse.xpand2.Generator</code>.</p></div><div class="section" title="Encoding"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_encoding"></a>Encoding</h4></div></div></div><p>For <span class="emphasis"><em>Xpand</em></span> it is important to have the file |
| encoding<a name="N115B3" class="indexterm"></a> in mind because of the |
| <span class="foreignphrase"><em class="foreignphrase">guillemet</em></span> characters <a name="N115BC" class="indexterm"></a> « » used to delimit keywords and property access. The |
| <code class="varname">fileEncoding</code> property<a name="N115C3" class="indexterm"></a> specifies the file encoding to use for reading the |
| templates, reading the protected regions and writing the generated |
| files. This property defaults to the default file encoding of your |
| JVM.</p><p>In a team that uses different operating systems or locales it is |
| a good idea to set the file encoding fixed for the Xpand project and |
| share the settings. Typical encodings used are UTF-8 or ISO-8859-1, |
| but any encoding having guillemet brackets is fine also.<sup>[<a href="#ftn.N115CB" name="N115CB" class="footnote">8</a>]</sup></p><p>An false encoding can result in an error message of the |
| generator during runtime:</p><pre class="programlisting">1108 ERROR WorkflowRunner - [ERROR]: no viable alternative at input 'Â' on line 1</pre><p>In this case you have to configure the input encoding. A |
| <span class="interface">ResourceManager</span> is used to set the input |
| encoding. Use the <code class="code">fileEncoding</code> property of the |
| <code class="code">ResourceManager</code> inside the generator component to |
| configure the encoding of templates and extensions.</p><p>Example for <span class="emphasis"><em>MWE</em></span>:</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| <metaModel idRef="mm_emf"/> |
| <expand |
| value="template::Template::main FOR model" /> |
| <outlet path="${src-gen}" > |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier" /> |
| </outlet> |
| <resourceManager class ="org.eclipse.xtend.expression.ResourceManagerDefaultImpl"> |
| <fileEncoding value="ISO-8859-1"/> |
| </resourceManager> |
| </component></pre><p>Example for <span class="emphasis"><em>MWE2</em></span>:</p><pre class="programlisting">component = org.eclipse.xpand2.Generator { |
| metaModel = org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel {} |
| expand = "templates::Template::main FOREACH model" |
| outlet = { |
| path = targetDir |
| } |
| resourceManager = org.eclipse.xtend.expression.ResourceManagerDefaultImpl { |
| fileEncoding = "ISO-8859-1" |
| } |
| } |
| </pre><p>The section <span class="emphasis"><em><a class="xref" href="#xpand_reference_output_configuration" title="Output configuration">Output configuration</a></em></span> describes |
| how to configure the encoding of the generated files.</p></div><div class="section" title="Metamodel"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_metamodel"></a>Metamodel</h4></div></div></div><p>The property <code class="varname">metaModel</code><a name="N115F9" class="indexterm"></a> is used to tell the generator engine on which |
| metamodels the <span class="emphasis"><em>Xpand</em></span> templates should be |
| evaluated. One can specify more than one metamodel here. Metamodel |
| implementations are required by the expression framework (see |
| <span class="emphasis"><em><a class="xref" href="#r10_expressions_language" title="Expressions">Expressions</a></em></span>) used |
| by <span class="emphasis"><em>Xpand2</em></span>. In the example above we configured the |
| Ecore metamodel using the <code class="classname">EMFMetaModel</code> |
| implementation shipped with the core part of the |
| <span class="emphasis"><em>Xpand</em></span> release.</p><p>A mandatory configuration is the <code class="varname">expand</code> |
| property. It expects a syntax similar to that of the |
| <code class="varname">EXPAND</code> statement (described above). The only |
| difference is that we omit the <code class="varname">EXPAND</code><a name="N11619" class="indexterm"></a> keyword. Instead, we specify the name of the |
| property.</p><p>Examples: </p><pre class="programlisting"><expand value="some::namespace::Template::define FOR mySlot"/></pre><p> |
| or: </p><pre class="programlisting"><expand value="some::namespace::Template::define('foo') FOREACH {mySlot1,mySlot2}"/></pre><p>The |
| expressions are evaluated using the workflow context. Each slot is |
| mapped to a variable. For the examples above the workflow context |
| needs to contain elements in the slots <code class="varname">'mySlot'</code>, |
| <code class="varname">'mySlot1'</code> and <code class="varname">'mySlot2'</code>. It is |
| also possible to specify some complex expressions here. If, for |
| instance, the slot <code class="varname">myModel</code> contains a collection of |
| model elements one could write:<a name="N11631" class="indexterm"></a> </p><pre class="programlisting"><expand value="some::namespace::Template::define FOREACH myModel.typeSelect(Entity)"/></pre><p>This |
| selects all elements of type <span class="emphasis"><em>Entity</em></span> contained in |
| the collection stored in the <code class="varname">myModel</code> slot.</p></div><div class="section" title="Output configuration"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_output_configuration"></a>Output configuration</h4></div></div></div><p>The second mandatory configuration is the specification of so |
| called outlets (a concept borrowed from AndroMDA). Outlets<a name="N11645" class="indexterm"></a> are responsible for writing the generated files to |
| disk.</p><p>Example <span class="emphasis"><em>MWE</em></span>: </p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| ... |
| <outlet path='main/src-gen'/> |
| <outlet name='TO_SRC' path='main/src' overwrite='false'> |
| <fileEncoding value='ISO-8859-1'/> |
| </outlet> |
| <fileEncoding value='ISO-8859-1'/> |
| ... |
| </component></pre><p>Example <span class="emphasis"><em>MWE2</em></span>: |
| </p><pre class="programlisting">component = org.eclipse.xpand2.Generator { |
| metaModel = org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel {} |
| expand = "templates::Template::main FOREACH model" |
| outlet = {path = 'main/src-gen'} |
| outlet = { |
| name='TO_SRC' |
| path='main/src' |
| overwrite= false |
| fileEncoding = 'ISO-8859-1' |
| } |
| fileEncoding = 'ISO-8859-1' |
| ... |
| } |
| </pre><p>In the examples there are two outlets configured. The first |
| one has no name and is therefore handled as the default outlet. |
| Default outlets are triggered by omitting an outlet name: |
| </p><pre class="programlisting">«FILE 'test/note.txt'» |
| # this goes to the default outlet |
| «ENDFILE»</pre><p>The configured base path is |
| '<code class="filename">main/src-gen</code>', so the file from above would go |
| to '<code class="filename">main/src-gen/test/note.txt</code>'.</p><p>The second outlet has a <code class="varname">name</code> ('TO_SRC') |
| specified. Additionally the flag <code class="varname">overwrite</code> is set |
| to <code class="varname">false</code> (defaults to <code class="varname">true</code>). The |
| following <span class="emphasis"><em>Xpand</em></span> fragment </p><pre class="programlisting">«FILE 'test/note.txt' TO_SRC» |
| # this goes to the TO_SRC outlet |
| «ENDFILE»</pre><p>would cause the generator to write the contents to |
| '<code class="filename">main/src/test/note.txt</code>' if the file does not |
| already exist (the <code class="varname">overwrite</code> flag).</p><p>Another option called <code class="varname">append</code> (defaults to |
| <code class="varname">false</code>) causes the generator to append the generated |
| text to an existing file. If <code class="varname">overwrite</code> is set to |
| <code class="varname">false</code> this flag has no effect.</p><p>The encoding<a name="N1168A" class="indexterm"></a> of the generated files can be configured at two |
| different levels. A file encoding can be defined for the complete |
| generator component. Therefore the <span class="emphasis"><em>fileEncoding</em></span> |
| property inside the component definition has to be used (see the |
| examples above). You can also define a file encoding at outlet level. |
| Therefore the <span class="emphasis"><em>fileEncoding</em></span> property inside the |
| outlet definition has to be used.</p></div><div class="section" title="PostProcessor"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_beautifier"></a>PostProcessor <a name="N1169A" class="indexterm"></a></h4></div></div></div><p>Beautifying the generated code is a good idea. It is very |
| important that generated code looks good, because developers should be |
| able to understand it. On the other hand template files should look |
| good, too. It is thus best practice to write nice looking template |
| files and not to care how the generated code looks - and then you run |
| a beautifier over the generated code to fix that problem. Of course, |
| if a beautifier is not available, or if white space has syntactical |
| meaning (as in Python), you would have to write your templates with |
| that in mind (using the minus character before closing brackets as |
| described in a preceding section).</p><p>The <span class="emphasis"><em>Xpand</em></span> workflow component can be |
| configured with multiple beautifiers:</p><pre class="programlisting"><outlet ...> |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| <postprocessor class="org.eclipse.xtend.typesystem.xsd.XMLBeautifier"/> |
| </outlet> |
| </pre><p>These are the two beautifiers delivered with |
| <span class="emphasis"><em>Xpand</em></span>. If you want to use your own beautifier, |
| you would just need to implement the |
| <code class="classname">PostProcessor</code> Java interface<a name="N116AD" class="indexterm"></a>: </p><pre class="programlisting">package org.eclipse.xpand2.output; |
| |
| public interface PostProcessor { |
| public void beforeWriteAndClose(FileHandle handle); |
| public void afterClose(FileHandle handle); |
| }</pre><p>The <code class="varname">beforeWriteAndClose</code> method is called |
| for each <code class="varname">ENDFILE</code> statement.</p><p>PostProcessors can also be used for othermeans than formatting, |
| like line counting.</p><div class="section" title="JavaBeautifier"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_javabeautifier"></a>JavaBeautifier</h5></div></div></div><p>The JavaBeautifier<a name="N116C2" class="indexterm"></a> is based on the Eclipse Java formatter provides base |
| beautifying for Java files.</p></div><div class="section" title="XmlBeautifier"><div class="titlepage"><div><div><h5 class="title"><a name="xpand_reference_xmlbeautifier"></a>XmlBeautifier</h5></div></div></div><p>The XmlBeautifier is based on <span class="emphasis"><em>dom4j</em></span> and |
| provides a single option <code class="varname">fileExtensions</code> (defaults |
| to "<code class="filename">.xml</code>, <code class="filename">.xsl</code>, |
| <code class="filename">.wsdd</code>, <code class="filename">.wsdl</code>") used to |
| specify which files should be pretty-printed.</p></div><div class="section" title="CppBeautifier"><div class="titlepage"><div><div><h5 class="title"><a name="N116DE"></a>CppBeautifier</h5></div></div></div><p>The CppBeautifier leverages CDT for formatting C/C++ sources. |
| Thus CDT is required to use this code formatter. To use this |
| beautifier the plugin |
| <span class="package">org.eclipse.xpand.support.cdt</span> must be added to |
| the plugin dependencies.</p></div></div><div class="section" title="Protected Region Configuration"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_reference_protected_region_configuration"></a>Protected Region Configuration</h4></div></div></div><p>Finally, you need to configure the protected region resolver, if |
| you want to use protected regions<a name="N116EC" class="indexterm"></a>. </p><pre class="programlisting"><prSrcPaths value="main/src"/> |
| <prDefaultExcludes value="false"/> |
| <prExcludes value="*.xml"/></pre><p>The |
| <span class="emphasis"><em>prSrcPaths</em></span><a name="N116F5" class="indexterm"></a>property points to a comma-separated list of |
| directories. The protected region resolver will scan these directories |
| for files containing activated protected regions.</p><p>There are several file names which are excluded by default: |
| </p><pre class="programlisting">RCS, SCCS, CVS, CVS.adm, RCSLOG, cvslog.*, tags, TAGS, .make.state, .nse_depinfo, *~, #*, |
| .#*, ',*', _$*,*$, *.old, *.bak, *.BAK, *.orig, *.rej, .del-*, *.a, *.olb, *.o, *.obj, |
| *.so, *.exe, *.Z,* .elc, *.ln, core, .svn</pre><p> If you do not want |
| to exclude any of these, you must set |
| <code class="varname">prDefaultExcludes</code> to false. </p><pre class="programlisting"><prDefaultExcludes value="false"/></pre><p> |
| If you want to add additional excludes, you should use the prExcludes |
| property. </p><pre class="programlisting"><prExcludes value="*.xml,*.hbm"/></pre><div class="note" title="Note" style="margin-left: 0.38in; margin-right: 0.38in;"><table border="0" summary="Note"><tr><td valign="top" align="center" rowspan="2" width="25"><img alt="[Note]" src="images/note.gif"></td><th align="left"></th></tr><tr><td valign="top" align="left"><p>It is bad practice to mix generated and non-generated code in |
| one artifact. Instead of using protected regions, you should try to |
| leverage the extension features of the used target language |
| (inheritance, inclusion, references, etc.) wherever possible. It is |
| very rare that the use of protected regions is an appropriate |
| solution.</p></td></tr></table></div></div><div class="section" title="VetoStrategy"><div class="titlepage"><div><div><h4 class="title"><a name="N11709"></a>VetoStrategy<a name="N1170C" class="indexterm"></a></h4></div></div></div><p>The <span class="emphasis"><em>Xpand</em></span> engine will generate code for |
| each processed <span class="property">FILE</span> statement. This implies that |
| files are written that might not have changed to the previous |
| generator run. Normally it does not matter that files are rewritten. |
| There are at least two good reasons when it is better to avoid |
| rewriting of files:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>The generated source code will be checked in. In general it |
| is not the recommended way to go to check in generated code, but |
| sometimes you will have to. Especially with CVS there is the |
| problem that rewritten files are recognized as modified, even if |
| they haven't changed. So the problem arises that identical files |
| get checked in again and again (or you revert it manually). When |
| working in teams the problem even becomes worse, since team |
| members will have conflicts when checking in.</p></li><li class="listitem"><p>When it can be predicted that the generator won't produce |
| different content before a file is even about to be created by a |
| FILE statement then this can boost performance. Of course it is |
| not trivial to predict that a specific file won't result in |
| different content before it is even created. This requires |
| information from a prior generator run and evaluation against the |
| current model to process. Usually a diff model would be used as |
| input for the decision.</p></li></ol></div><p>Case 1) will prevent file writing after a |
| <span class="property">FILE</span> statement has been evaluated, case 2) will |
| prevent creating a file at all.</p><p>To achieve this it is possible to add Veto Strategies to the |
| generator, which are implementations of interface |
| <code class="classname">org.eclipse.xpand2.output.VetoStrategy</code> or |
| <code class="classname">org.eclipse.xpand2.output.VetoStrategy2</code>. Use |
| <code class="classname">VetoStrategy2</code> if you implement your own.</p><p><code class="classname">VetoStrategy2</code> declares two |
| methods:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="methodname">boolean hasVetoBeforeOpen |
| (FileHandle)</code></p><p>This method will be called before a file is being opened and |
| generated. Return true to suppress the file creation.</p></li><li class="listitem"><p><code class="methodname">boolean hasVeto (FileHandle)</code></p><p>This method will be called after a file has been produced |
| and after all configured PostProcessors have been invoked. Return |
| true to suppress writing the file.</p></li></ul></div><p>Veto Strategies are configured per Outlet. It is possible to add |
| multiple stratgy instances to each Outlet.</p><pre class="programlisting"> <component id="generator" class="org.eclipse.xpand2.Generator" skipOnErrors="true"> |
| <metaModel class="org.eclipse.xtend.typesystem.uml2.UML2MetaModel"/> |
| <expand value="templates::Root::Root FOR model"/> |
| <fileEncoding value="ISO-8859-1"/> |
| <outlet path="src-gen"> |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| <span class="bold"><strong><vetoStrategy class="org.eclipse.xpand2.output.NoChangesVetoStrategy"/></strong></span> |
| </outlet> |
| </component> |
| </pre><p>One <code class="classname">VetoStrategy</code> is already provided. |
| The |
| <code class="classname">org.eclipse.xpand2.output.NoChangesVetoStrategy</code> |
| <a name="N1174F" class="indexterm"></a>is a simple implementation that will compare the |
| produced output, after it has been postprocessed, with the target |
| file. If the content is identical the strategy vetoes the file |
| writing. This strategy is effective, but has two severe |
| drawbacks:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>The file has been created at least in memory before. This |
| consumes time and memory. If applying code formatting this usually |
| implies that the file is temporarily written.</p></li><li class="listitem"><p>The existing file must be read into memory. This also costs |
| time and memory.</p></li></ol></div><p>Much better would be to even prevent the creation of files by |
| having a valid implementation for the |
| <code class="classname">hasVetoBeforeOpen()</code> method. Providing an |
| implementation that predicts that files do not have to be created |
| requires domain knowledge, thus a standard implementation is not |
| available.</p><p>The number of skipped files will be reported by the Generator |
| component like this:</p><pre class="programlisting">2192 INFO - Generator(generator): generating <...> |
| 3792 INFO - <span class="bold"><strong>Skipped writing of 2 files to outlet</strong></span> [default](src-gen) |
| </pre></div></div><div class="section" title="Example for using Aspect-Oriented Programming in Xpand"><div class="titlepage"><div><div><h3 class="title"><a name="aop_template_introduction"></a>Example for using Aspect-Oriented Programming in |
| <span class="emphasis"><em>Xpand</em></span></h3></div></div></div><p><a name="N1176F" class="indexterm"></a>This example shows how to use aspect-oriented programming |
| techniques in <span class="emphasis"><em>Xpand</em></span> templates. It is applicable to |
| EMF based and <span class="emphasis"><em>Classic</em></span> systems. However, we explain |
| the idea based on the <span class="emphasis"><em>emfExample</em></span>. Hence you should |
| read that before.</p></div><div class="section" title="The Problem"><div class="titlepage"><div><div><h3 class="title"><a name="aop_template_the_problem"></a>The Problem</h3></div></div></div><p>There are many circumstances when template-AOP is useful. Here are |
| two examples:</p><p><span class="bold"><strong>Scenario 1:</strong></span> Assume you have a |
| nice generator that generates certain artifacts. The generator (or |
| cartridge) might be a third party product, delivered in a single JAR |
| file. Still you might want to adapt certain aspects of the generation |
| process <span class="emphasis"><em>without modifying the original |
| generator</em></span>.</p><p><span class="bold"><strong>Scenario 2:</strong></span> You are building a |
| family of generators that can generate variations of the generate code, |
| e.g. Implementations for different embedded platforms. In such a |
| scenario, you need to be able to express those differences |
| (variabilities) sensibly without creating a non-understandable chaos of |
| <span class="emphasis"><em>if</em></span> statements in the templates.</p></div><div class="section" title="Example"><div class="titlepage"><div><div><h3 class="title"><a name="aop_template_example"></a>Example</h3></div></div></div><p>To illustrate the idea of extending a generator without "touching" |
| it, let us create a new project called |
| <code class="classname">org.eclipse.demo.emf.datamodel.generator-aop</code>. The |
| idea is that it will "extend" the original |
| <code class="classname">org.eclipse.demo.emf.datamodel.generator</code> project |
| introduced in the <span class="emphasis"><em>emfExample</em></span>. So this new projects |
| needs to have a project dependency to the former one.</p><div class="section" title="Templates"><div class="titlepage"><div><div><h4 class="title"><a name="aop_template_example_templates"></a>Templates</h4></div></div></div><p>An AOP system always needs to define a join point<a name="N117A9" class="indexterm"></a> model; this is, you have to define, at which locations |
| of a (template) program you can add additional (template) code. In |
| <span class="emphasis"><em>Xpand</em></span>, the join points are simply templates (i.e. |
| <span class="emphasis"><em>DEFINE .. ENDDEFINE</em></span>) blocks. An "aspect template" |
| can be declared <span class="emphasis"><em>AROUND</em></span><a name="N117B5" class="indexterm"></a> previously existing templates. If you take a look at |
| the <code class="classname">org.eclipse.demo.emf.datamodel.generator</code> |
| source folder of the project, you can find the |
| <code class="filename">Root.xpt</code> template file. Inside, you can find a |
| template called <code class="classname">Impl</code> that generates the |
| implementation of the JavaBean.</p><pre class="programlisting">«DEFINE Entity FOR data::Entity» |
| «FILE baseClassFileName() » |
| // generated at «timestamp()» |
| public abstract class «baseClassName()» { |
| «EXPAND Impl» |
| } |
| «ENDFILE» |
| «ENDDEFINE» |
| |
| «DEFINE Impl FOR data::Entity» |
| «EXPAND GettersAndSetters» |
| «ENDDEFINE» |
| |
| «DEFINE Impl FOR data::PersistentEntity» |
| «EXPAND GettersAndSetters» |
| public void save() { |
| |
| } |
| «ENDDEFINE»</pre><p>What we now want to accomplish is this: Whenever the |
| <span class="emphasis"><em>Impl</em></span> template is executed, we want to run an |
| additional template that generates additional code (for example, some |
| kind of meta information for a given framework. The specific code at |
| this place is not important for the example here).</p><p>So, in our new project, we define the following template |
| file:</p><pre class="programlisting">«AROUND Impl FOR data::Entity» |
| «FOREACH attribute AS a» |
| public static final AttrInfo «a.name»Info = new AttrInfo( |
| "«a.name»", «a.type».class ); |
| «ENDFOREACH» |
| «targetDef.proceed()» |
| «ENDAROUND»</pre><p>So, this new template wraps around the existing template called |
| <code class="classname">Impl</code> It first generates additional code and |
| then forwards the execution to the original template using |
| <code class="methodname">targetDef.proceed()</code>. So, in effect, this is a |
| <code class="varname">BEFORE</code> advice. Moving the |
| <code class="methodname">proceed</code> statement to the beginning makes it |
| an <code class="varname">AFTER</code> advice, omitting it, makes it an |
| override.</p></div><div class="section" title="Workflow File"><div class="titlepage"><div><div><h4 class="title"><a name="aop_template_example_workflow_file"></a>Workflow File<a name="N117E4" class="indexterm"></a></h4></div></div></div><p>Let us take a look at the workflow file to run this |
| generator:</p><pre class="programlisting"><workflow> |
| <cartridge file="workflow.mwe"/> |
| <component adviceTarget="generator" |
| id="reflectionAdvice" |
| class="org.eclipse.xpand2.GeneratorAdvice"> |
| <advices value="templates::Advices"/> |
| </component> |
| </workflow></pre><p>Mainly, what we do here, is to call the original workflow file. |
| It has to be available from the classpath. After this cartridge call, |
| we define an additional workflow component, a so called |
| <span class="emphasis"><em>advice component</em></span>. It specifies |
| <span class="emphasis"><em>generator</em></span> as its |
| <span class="emphasis"><em>adviceTarget</em></span>. That means, that all the properties |
| we define inside this advice component will be added to the component |
| referenced by name in the <span class="emphasis"><em>adviceTarget</em></span> instead. |
| In our case, this is the generator. So, in effect, we add the |
| <code class="classname"><advices value="templates::Advices" /></code> to |
| the original generator component (without invasively modifying its own |
| definition). This contributes the advice templates to the |
| generator.</p></div><div class="section" title="Running the new generator"><div class="titlepage"><div><div><h4 class="title"><a name="aop_template_example_running_the_new_generator"></a>Running the new generator</h4></div></div></div><p>Running the generator produces the following code:</p><pre class="programlisting">public abstract class PersonImplBase { |
| public static final AttrInfo |
| nameInfo = new AttrInfo("name", String.class); |
| public static final AttrInfo |
| name2Info = new AttrInfo("name2", String.class); |
| private String name; |
| private String name2; |
| |
| public void setName(String value) { |
| this.name = value; |
| } |
| |
| public String getName() { |
| return this.name; |
| } |
| |
| public void setName2(String value) { |
| this.name2 = value; |
| } |
| |
| public String getName2() { |
| return this.name2; |
| } |
| }</pre></div></div><div class="section" title="More Aspect Orientation"><div class="titlepage"><div><div><h3 class="title"><a name="aop_template_more_ao"></a>More Aspect Orientation</h3></div></div></div><p>In general, the syntax for the |
| <span class="emphasis"><em>AROUND</em></span><a name="N11810" class="indexterm"></a> construct is as follows:</p><pre class="programlisting">«AROUND fullyQualifiedDefinitionNameWithWildcards |
| (Paramlist (*)?) FOR TypeName» |
| do Stuff |
| «ENDAROUND»</pre><p>Here are some examples:</p><pre class="programlisting">«AROUND *(*) FOR Object»</pre><p>matches all templates</p><pre class="programlisting">«AROUND *define(*) FOR Object»</pre><p>matches all templates with <span class="emphasis"><em>define</em></span> at the end |
| of its name and any number of parameters</p><pre class="programlisting">«AROUND org::eclipse::xpand2::* FOR Entity»</pre><p>matches all templates with namespace |
| <span class="emphasis"><em>org::eclipse::xpand2::</em></span> that do not have any |
| parameters and whose type is Entity or a subclass</p><pre class="programlisting">«AROUND *(String s) FOR Object»</pre><p>matches all templates that have exactly one |
| <code class="classname">String</code> parameter</p><pre class="programlisting">«AROUND *(String s,*) FOR Object»</pre><p>matches all templates that have at least one |
| <code class="classname">String</code> parameter</p><pre class="programlisting">«AROUND my::Template::definition(String s) FOR Entity»</pre><p>matches exactly this single definition</p><p>Inside an <code class="varname">AROUND</code>, there is the variable |
| <code class="varname">targetDef</code>, which has the type |
| <code class="classname">xpand2::Definition</code>. On this variable, you can |
| call <code class="methodname">proceed</code>, and also query a number of other |
| things:</p><pre class="programlisting">«AROUND my::Template::definition(String s) FOR String» |
| log('invoking '+«targetDef.name»+' with '+this) |
| «targetDef.proceed()» |
| «ENDAROUND»</pre></div></div><div class="section" title="Profiler"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="r10_profiler"></a>Profiler</h2></div></div></div><p>The <span class="emphasis"><em>ProfilerComponent</em></span> allows you to measure the |
| time each check, Xtend function or Xpand define needed to be executed in |
| your workflow. It does so by acting as a callback of the |
| <span class="emphasis"><em>CheckComponent</em></span>, <span class="emphasis"><em>XtendComponent</em></span> |
| and <span class="emphasis"><em>XpandComponent</em></span> where the time of each call will |
| be stored in a profiling model. From this data the profiler eventually |
| derives execution times with and without children, callers/callees with |
| the corresponding call counts and finally a call graph with respect to |
| recursive calls. A set of Xpand templates can transform the model to an |
| HTML report or a text file in the GNU GProf format.</p><div class="figure"><a name="N1185F"></a><p class="title"><b>Figure 2. Sample HTML output of the profiler</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/Xpand/profiler.png" width="513" alt="Sample HTML output of the profiler"></div></div></div><br class="figure-break"><p>Use the <span class="emphasis"><em>ProfilerComponent</em></span> to wrap other |
| components inside a workflow. Denote a <span class="emphasis"><em>resultSlot</em></span> |
| where the profiler stores the model in the end. Then, refer to this |
| component via <span class="emphasis"><em>idRef</em></span> as a callback. As soon as the |
| component-tag of the profiler closes, it stores the derived profiling |
| model in the given slot. You are free to transform this model or you can |
| re-use one of the templates that come with profiler.</p><pre class="programlisting"> |
| <component id="profiler" class="org.eclipse.xtend.profiler.ProfilerComponent"> |
| <resultSlot value="profilingResult" /> |
| |
| <component class="org.eclipse.xtend.check.CheckComponent"> |
| <vetoableCallback idRef="profiler" /> |
| ... |
| </component> |
| <component class="org.eclipse.xtend.XtendComponent"> |
| <vetoableCallback idRef="profiler" /> |
| ... |
| </component> |
| <component class="org.eclipse.xpand2.Generator"> |
| <vetoableCallback idRef="profiler" /> |
| ... |
| </component> |
| </component> |
| |
| <component class="org.eclipse.xpand2.Generator" fileEncoding="ISO-8859-1"> |
| <metaModel idRef="mm"/> |
| <expand value="org::eclipse::xtend::profiler::templates::Html::Main FOR profilingResult"/> |
| <outlet overwrite="true" path="profiling"/> |
| </component> |
| </pre><p>Currently, there are two different templates available to render the |
| profiling model </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>org::eclipse::xtend::profiler::templates::Html::Main</p></li><li class="listitem"><p>org::eclipse::xtend::profiler::templates::GProf::Main</p></li></ul></div><p>The Xpand Wizard will produce a workflow called |
| <span class="emphasis"><em>workflowWithProfiler.mwe</em></span> that demonstrates the |
| capabilities of the profiler. It puts the result in the folder |
| <span class="emphasis"><em>profiling</em></span>.</p></div><div class="footnotes"><br><hr align="left" width="100"><div class="footnote"><p><sup>[<a href="#N115CB" name="ftn.N115CB" class="para">8</a>] </sup>On Mac OSX the default encoding is MacRoman, which is not a |
| good choice, since other operating systems are not aware of this |
| encoding. It is recommended to set the encoding to some more |
| common encoding, e.g. UTF-8, maybe even for the whole |
| workspace.</p></div></div></div><div class="chapter" title="Chapter 3. Built-in types API documentation"><div class="titlepage"><div><div><h2 class="title"><a name="builtin_api"></a>Chapter 3. Built-in types API documentation</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#Object.html"><code class="classname">Object</code></a></span></dt><dt><span class="section"><a href="#String.html"><code class="classname">String</code></a></span></dt><dt><span class="section"><a href="#Integer.html"><code class="classname">Integer</code></a></span></dt><dt><span class="section"><a href="#Boolean.html"><code class="classname">Boolean</code></a></span></dt><dt><span class="section"><a href="#Real.html"><code class="classname">Real</code></a></span></dt><dt><span class="section"><a href="#Collection.html"><code class="classname">Collection</code></a></span></dt><dt><span class="section"><a href="#List.html"><code class="classname">List</code></a></span></dt><dt><span class="section"><a href="#Set.html"><code class="classname">Set</code></a></span></dt><dt><span class="section"><a href="#xpand2_Type.html"><code class="classname">xpand2::Type</code></a></span></dt><dt><span class="section"><a href="#xpand2_Feature.html"><code class="classname">xpand2::Feature</code></a></span></dt><dt><span class="section"><a href="#xpand2_Property.html"><code class="classname">xpand2::Property</code></a></span></dt><dt><span class="section"><a href="#xpand2_Operation.html"><code class="classname">xpand2::Operation</code></a></span></dt><dt><span class="section"><a href="#xpand2_StaticProperty.html"><code class="classname">xpand2::StaticProperty</code></a></span></dt><dt><span class="section"><a href="#Void.html"><code class="classname">Void</code></a></span></dt><dt><span class="section"><a href="#xtend_AdviceContext.html"><code class="classname">xtend::AdviceContext</code></a></span></dt><dt><span class="section"><a href="#xpand2_Definition.html"><code class="classname">xpand2::Definition</code></a></span></dt><dt><span class="section"><a href="#xpand2_Iterator.html"><code class="classname">xpand2::Iterator</code></a></span></dt></dl></div><div class="section" title="Object"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Object.html"></a><code class="classname">Object</code></h2></div></div></div><p> |
| Supertype: |
| none |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Object_Properties"></a><p class="title"><b>Table 1. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#xpand2_Type.html" title="xpand2::Type"><code class="classname">xpand2::Type</code></a> |
| </td><td align="left"> |
| <code class="methodname">metaType</code> |
| </td><td align="left"> |
| returns this object's meta type. |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Object_Operations"></a><p class="title"><b>Table 2. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">==</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname"><</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toString</code> |
| () |
| </td><td align="left"> |
| returns the String representation of this object. (Calling Java's toString() method) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname"><=</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">!=</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">></code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">compareTo</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| Compares this object with the specified object for order. Returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">>=</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="String"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="String.html"></a><code class="classname">String</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="String_Properties"></a><p class="title"><b>Table 3. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">length</code> |
| </td><td align="left"> |
| the length of this string |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="String_Operations"></a><p class="title"><b>Table 4. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toLowerCase</code> |
| () |
| </td><td align="left"> |
| Converts all of the characters in this String to lower case using the rules of the default locale (from Java) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">+</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| concatenates two strings |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">toCharList</code> |
| () |
| </td><td align="left"> |
| splits this String into a List[String] containing Strings of length 1 |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toFirstUpper</code> |
| () |
| </td><td align="left"> |
| Converts the first character in this String to upper case using the rules of the default locale (from Java) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">subString</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>, <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| Returns a new string that is a substring of this string. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">trim</code> |
| () |
| </td><td align="left"> |
| Returns a copy of the string, with leading and trailing whitespace omitted. (from Java 1.4) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toFirstLower</code> |
| () |
| </td><td align="left"> |
| Converts the first character in this String to lower case using the rules of the default locale (from Java) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toUpperCase</code> |
| () |
| </td><td align="left"> |
| Converts all of the characters in this String to upper case using the rules of the default locale (from Java) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">split</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Splits this string around matches of the given regular expression (from Java 1.4) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">startsWith</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Tests if this string starts with the specified prefix. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">matches</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Tells whether or not this string matches the given regular expression. (from Java 1.4) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">asInteger</code> |
| () |
| </td><td align="left"> |
| Returns an Integer object holding the value of the specified String (from Java 1.5) |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">contains</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Tests if this string contains substring. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">endsWith</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Tests if this string ends with the specified prefix. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">replaceFirst</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>, <a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Replaces the first substring of this string that matches the given regular expression with the given replacement. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">replaceAll</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>, <a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| Replaces each substring of this string that matches the given regular expression with the given replacement. |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="Integer"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Integer.html"></a><code class="classname">Integer</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Integer_Operations"></a><p class="title"><b>Table 5. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">upTo</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| returns a List of Integers starting with the value of the target expression, up to the value of the specified Integer, incremented by one, e.g. '1.upTo(5)' evaluates to {1,2,3,4,5} |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">>=</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">==</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">!=</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">upTo</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>, <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| returns a List of Integers starting with the value of the target expression, up to the value of the first paramter, incremented by the second parameter, e.g. '1.upTo(10, 2)' evaluates to {1,3,5,7,9} |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">-</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">+</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname"><=</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname"><</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">*</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">-</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">></code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">/</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="Boolean"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Boolean.html"></a><code class="classname">Boolean</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Boolean_Operations"></a><p class="title"><b>Table 6. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">!</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="Real"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Real.html"></a><code class="classname">Real</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Real_Operations"></a><p class="title"><b>Table 7. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a> |
| </td><td align="left"> |
| <code class="methodname">*</code> |
| (<a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">>=</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname"><=</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a> |
| </td><td align="left"> |
| <code class="methodname">-</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">==</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">!=</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname"><</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a> |
| </td><td align="left"> |
| <code class="methodname">-</code> |
| (<a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a> |
| </td><td align="left"> |
| <code class="methodname">/</code> |
| (<a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">></code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a> |
| </td><td align="left"> |
| <code class="methodname">+</code> |
| (<a class="link" href="#Real.html" title="Real"><code class="classname">Real</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="Collection"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Collection.html"></a><code class="classname">Collection</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Collection_Properties"></a><p class="title"><b>Table 8. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">isEmpty</code> |
| </td><td align="left"> |
| returns true if this Collection is empty |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">size</code> |
| </td><td align="left"> |
| returns the size of this Collection |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="Collection_Operations"></a><p class="title"><b>Table 9. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">contains</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| returns true if this collection contains the specified object. otherwise false. returns this Collection. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">toList</code> |
| () |
| </td><td align="left"> |
| converts this collection to List |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">toSet</code> |
| () |
| </td><td align="left"> |
| converts this collection to Set |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">flatten</code> |
| () |
| </td><td align="left"> |
| returns a flattened List. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">intersect</code> |
| (<a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a>) |
| </td><td align="left"> |
| returns a new Set, containing only the elements contained in this and the specified Collection |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toString</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| concatenates each contained element (using toString()), separated by the specified String. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </td><td align="left"> |
| <code class="methodname">removeAll</code> |
| (<a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a>) |
| </td><td align="left"> |
| removes all elements contained in the specified collection from this Collection if contained (modifies it!). returns this Collection. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </td><td align="left"> |
| <code class="methodname">remove</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| removes the specified element from this Collection if contained (modifies it!). returns this Collection. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">without</code> |
| (<a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a>) |
| </td><td align="left"> |
| returns a new Set, containing all elements from this Collection without the elements from specified Collection |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </td><td align="left"> |
| <code class="methodname">addAll</code> |
| (<a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a>) |
| </td><td align="left"> |
| adds all elements to the Collection (modifies it!). returns this Collection. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </td><td align="left"> |
| <code class="methodname">add</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| adds an element to the Collection (modifies it!). returns this Collection. |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">union</code> |
| (<a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a>) |
| </td><td align="left"> |
| returns a new Set, containing all elements from this and the specified Collection |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">containsAll</code> |
| (<a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a>) |
| </td><td align="left"> |
| returns true if this collection contains each element contained in the specified collection. otherwise false. returns this Collection. |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="List"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="List.html"></a><code class="classname">List</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="List_Operations"></a><p class="title"><b>Table 10. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">withoutFirst</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">last</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">indexOf</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">withoutLast</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </td><td align="left"> |
| <code class="methodname">reverse</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">first</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">get</code> |
| (<a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="Set"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Set.html"></a><code class="classname">Set</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Collection.html" title="Collection"><code class="classname">Collection</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| This type does not define any operations. |
| |
| |
| </p></div><div class="section" title="xpand2::Type"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_Type.html"></a><code class="classname">xpand2::Type</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Type_Properties"></a><p class="title"><b>Table 11. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">name</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">allStaticProperties</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">documentation</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">superTypes</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">allProperties</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">allFeatures</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Set.html" title="Set"><code class="classname">Set</code></a> |
| </td><td align="left"> |
| <code class="methodname">allOperations</code> |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Type_Operations"></a><p class="title"><b>Table 12. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#xpand2_StaticProperty.html" title="xpand2::StaticProperty"><code class="classname">xpand2::StaticProperty</code></a> |
| </td><td align="left"> |
| <code class="methodname">getStaticProperty</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#xpand2_Feature.html" title="xpand2::Feature"><code class="classname">xpand2::Feature</code></a> |
| </td><td align="left"> |
| <code class="methodname">getFeature</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>, <a class="link" href="#List.html" title="List"><code class="classname">List</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">isInstance</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#xpand2_Property.html" title="xpand2::Property"><code class="classname">xpand2::Property</code></a> |
| </td><td align="left"> |
| <code class="methodname">getProperty</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">newInstance</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">isAssignableFrom</code> |
| (<a class="link" href="#xpand2_Type.html" title="xpand2::Type"><code class="classname">xpand2::Type</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#xpand2_Operation.html" title="xpand2::Operation"><code class="classname">xpand2::Operation</code></a> |
| </td><td align="left"> |
| <code class="methodname">getOperation</code> |
| (<a class="link" href="#String.html" title="String"><code class="classname">String</code></a>, <a class="link" href="#List.html" title="List"><code class="classname">List</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="xpand2::Feature"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_Feature.html"></a><code class="classname">xpand2::Feature</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Feature_Properties"></a><p class="title"><b>Table 13. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">name</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#xpand2_Type.html" title="xpand2::Type"><code class="classname">xpand2::Type</code></a> |
| </td><td align="left"> |
| <code class="methodname">returnType</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">documentation</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#xpand2_Type.html" title="xpand2::Type"><code class="classname">xpand2::Type</code></a> |
| </td><td align="left"> |
| <code class="methodname">owner</code> |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| This type does not define any operations. |
| |
| |
| </p></div><div class="section" title="xpand2::Property"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_Property.html"></a><code class="classname">xpand2::Property</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#xpand2_Feature.html" title="xpand2::Feature"><code class="classname">xpand2::Feature</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Property_Operations"></a><p class="title"><b>Table 14. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Void.html" title="Void"><code class="classname">Void</code></a> |
| </td><td align="left"> |
| <code class="methodname">set</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>, <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">get</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="xpand2::Operation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_Operation.html"></a><code class="classname">xpand2::Operation</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#xpand2_Feature.html" title="xpand2::Feature"><code class="classname">xpand2::Feature</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Operation_Operations"></a><p class="title"><b>Table 15. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">getParameterTypes</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">evaluate</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>, <a class="link" href="#List.html" title="List"><code class="classname">List</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="xpand2::StaticProperty"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_StaticProperty.html"></a><code class="classname">xpand2::StaticProperty</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#xpand2_Feature.html" title="xpand2::Feature"><code class="classname">xpand2::Feature</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::StaticProperty_Operations"></a><p class="title"><b>Table 16. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">get</code> |
| () |
| </td><td align="left"> |
| returns the static value |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="Void"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Void.html"></a><code class="classname">Void</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| This type does not define any properties. |
| |
| |
| </p><p> |
| |
| |
| This type does not define any operations. |
| |
| |
| </p></div><div class="section" title="xtend::AdviceContext"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xtend_AdviceContext.html"></a><code class="classname">xtend::AdviceContext</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xtend::AdviceContext_Properties"></a><p class="title"><b>Table 17. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">paramTypes</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">name</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">paramNames</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">paramValues</code> |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xtend::AdviceContext_Operations"></a><p class="title"><b>Table 18. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">proceed</code> |
| (<a class="link" href="#List.html" title="List"><code class="classname">List</code></a>) |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </td><td align="left"> |
| <code class="methodname">proceed</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="xpand2::Definition"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_Definition.html"></a><code class="classname">xpand2::Definition</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Definition_Properties"></a><p class="title"><b>Table 19. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">paramTypes</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">name</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#List.html" title="List"><code class="classname">List</code></a> |
| </td><td align="left"> |
| <code class="methodname">paramNames</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#xpand2_Type.html" title="xpand2::Type"><code class="classname">xpand2::Type</code></a> |
| </td><td align="left"> |
| <code class="methodname">targetType</code> |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Definition_Operations"></a><p class="title"><b>Table 20. Operations</b></p><div class="table-contents"><table summary="Operations" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Return type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Void.html" title="Void"><code class="classname">Void</code></a> |
| </td><td align="left"> |
| <code class="methodname">proceed</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#String.html" title="String"><code class="classname">String</code></a> |
| </td><td align="left"> |
| <code class="methodname">toString</code> |
| () |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Void.html" title="Void"><code class="classname">Void</code></a> |
| </td><td align="left"> |
| <code class="methodname">proceed</code> |
| (<a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a>, <a class="link" href="#List.html" title="List"><code class="classname">List</code></a>) |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p></div><div class="section" title="xpand2::Iterator"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xpand2_Iterator.html"></a><code class="classname">xpand2::Iterator</code></h2></div></div></div><p> |
| Supertype: |
| <a class="link" href="#Object.html" title="Object"><code class="classname">Object</code></a> |
| </p><p> |
| |
| |
| </p><div class="table"><a name="xpand2::Iterator_Properties"></a><p class="title"><b>Table 21. Properties</b></p><div class="table-contents"><table summary="Properties" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Type</th><th align="left">Name</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">lastIteration</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Boolean.html" title="Boolean"><code class="classname">Boolean</code></a> |
| </td><td align="left"> |
| <code class="methodname">firstIteration</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">elements</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">counter0</code> |
| </td><td align="left"> |
| |
| </td></tr><tr><td align="left"> |
| <a class="link" href="#Integer.html" title="Integer"><code class="classname">Integer</code></a> |
| </td><td align="left"> |
| <code class="methodname">counter1</code> |
| </td><td align="left"> |
| |
| </td></tr></tbody></table></div></div><p><br class="table-break"> |
| |
| |
| </p><p> |
| |
| |
| This type does not define any operations. |
| |
| |
| </p></div></div><div class="chapter" title="Chapter 4. Stdlib"><div class="titlepage"><div><div><h2 class="title"><a name="stdlib_reference"></a>Chapter 4. Stdlib</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#N123CE">Introduction</a></span></dt><dt><span class="section"><a href="#N123D6">Stdlib extensions</a></span></dt><dd><dl><dt><span class="section"><a href="#N123E3">IO extensions</a></span></dt><dt><span class="section"><a href="#N124C0">Counter extensions</a></span></dt><dt><span class="section"><a href="#N12520">Properties extensions</a></span></dt><dt><span class="section"><a href="#N1256E">Element properties extensions</a></span></dt><dt><span class="section"><a href="#N125B0">Issues extensions</a></span></dt><dt><span class="section"><a href="#N1262A">Naming extensions</a></span></dt><dt><span class="section"><a href="#N12684">Globalvar extensions</a></span></dt><dt><span class="section"><a href="#N1269B">Cloning extensions</a></span></dt><dt><span class="section"><a href="#N126DD">Cross references extensions</a></span></dt><dt><span class="section"><a href="#N12704">UID extensions</a></span></dt><dt><span class="section"><a href="#N1274E">Mixin extensions</a></span></dt><dt><span class="section"><a href="#N1278E">Tracing extensions</a></span></dt></dl></dd><dt><span class="section"><a href="#N12811">Stdlib workflow components</a></span></dt><dd><dl><dt><span class="section"><a href="#N12816">SystemCommand</a></span></dt><dt><span class="section"><a href="#N12879">SlotCopier</a></span></dt><dt><span class="section"><a href="#N128C4">SlotListAdder</a></span></dt><dt><span class="section"><a href="#N12913">SlotPrinter</a></span></dt></dl></dd></dl></div><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N123CE"></a>Introduction</h2></div></div></div><p>Xpand delivers a set of small useful utility extensions and |
| components in the <span class="package">org.eclipse.xpand.util.stdlib</span> |
| package. You need to add a dependency to this plugin if you want to use |
| it.</p></div><div class="section" title="Stdlib extensions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N123D6"></a>Stdlib extensions</h2></div></div></div><p>This section describes the components and extensions provided by |
| Stdlib. We use the shortcut <span class="emphasis"><em>xpand.util.stdlib...</em></span> for |
| component classes in package |
| <span class="package">org.eclipse.xtend.util.stdlib</span> in workflow |
| configurations for convenience.</p><p>Note that many functions of the Stdlib make use of static variables |
| in their Java implementation, thus the values are kept through a complete |
| MWE workflow. Also, because of the static implementation, the features are |
| not threadsafe.</p><div class="section" title="IO extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N123E3"></a>IO extensions</h3></div></div></div><p>This is an extremely useful library to print information to the |
| logging facility. It is really valuable through transformation processes |
| or for complex expressions to know what exactly expressions are |
| evaluated to.</p><p><span class="emphasis"><em>Extension:</em></span> |
| <code class="classname">org::eclipse::xtend::util::stdlib::io</code></p><div class="section" title="debug (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N123EE"></a>debug (Object o)</h4></div></div></div><p>Logs an object with DEBUG level to the logger.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The object to dump.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object o</p></div><div class="section" title="info (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N123FE"></a>info (Object o)</h4></div></div></div><p>Logs an object with INFO level to the logger.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The object to dump.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object o</p></div><div class="section" title="error (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N1240E"></a>error (Object o)</h4></div></div></div><p>Logs an object with ERROR level to the logger.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The object to dump.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object o</p></div><div class="section" title="syserr (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N1241E"></a>syserr (Object o)</h4></div></div></div><p>Prints an object to System.err.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The object that should be printed. <code class="code">null</code> is |
| allowed.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object o</p></div><div class="section" title="syserr (Object o, String prefix)"><div class="titlepage"><div><div><h4 class="title"><a name="N12431"></a>syserr (Object o, String prefix)</h4></div></div></div><p>Prints an object to System.err.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The object that should be printed. <code class="code">null</code> is |
| allowed.</p></li><li class="listitem"><p>prefix - A prefix string for the message.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object o</p></div><div class="section" title="syserr (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N12447"></a>syserr (Object o)</h4></div></div></div><p>Prints an object to System.err.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The object that should be printed. <code class="code">null</code> is |
| allowed.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object o</p></div><div class="section" title="throwError (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N1245A"></a>throwError (Object o)</h4></div></div></div><p>Throws an IllegalStateMessage.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - The exception message.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Nothing, since an exception is |
| thrown.</p></div><div class="section" title="String includeFile (String filePath, String encoding)"><div class="titlepage"><div><div><h4 class="title"><a name="N1246A"></a>String includeFile (String filePath, String encoding)</h4></div></div></div><p>Reads the content of a file.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>filePath - Path to the file</p><p>encoding - File encoding to use for reading</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> File content.</p></div><div class="section" title="String includeFile (String filePath)"><div class="titlepage"><div><div><h4 class="title"><a name="N1247C"></a>String includeFile (String filePath)</h4></div></div></div><p>Reads the content of a file.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>filePath - Path to the file</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> File content.</p></div><div class="section" title="Examples"><div class="titlepage"><div><div><h4 class="title"><a name="N1248C"></a>Examples</h4></div></div></div><pre class="programlisting">import data; |
| extension org.eclipse.xtend.util.stdlib::io; |
| create DataModel this duplicate(DataModel s): |
| entity.addAll( s.entity.duplicate() ) -> |
| setName(s.name); |
| |
| create Entity this duplicate(Entity old): |
| (old.name+" has "+old.reference.size+" references").info() -> |
| old.reference.name.info() -> |
| </pre><p>This leads to the following output on the console:</p><pre class="programlisting">922 INFO - Person has 1 references |
| 923 INFO - [autos] |
| 926 INFO - Vehicle has 0 references |
| 926 INFO - [] |
| </pre><p>Of course IO extension functions can also be used within Xpand, |
| but if used for logging purposes you have to deal with one side |
| effect: Since the functions return the passed object (the result of an |
| expression, in the simplest case just a string) and Xpand prints out |
| expression results to the opened file, the message will be shown on |
| the console, but also be in the result file. This you might want to |
| avoid, so you can use a small trick for this: after calling a log |
| function use the chaining operator and let the result of the |
| expression be an empty string:</p><pre class="programlisting">«EXTENSION org::eclipse::xtend::util::stdlib::io» |
| ... |
| «DEFINE javaClass FOR Entity» |
| «REM»The following expression will dump the feature names without producing output |
| as side effect«ENDREM» |
| «features.name.info() -> ""»</pre><p>This will produce this output on the console:</p><pre class="programlisting">1122 INFO IOExtensions - [name, age, address] |
| 1740 INFO IOExtensions - [street, zip, city]</pre><p>Each function returns the object on which they have been called, |
| so you can build chain expressions. Or, in other words, if you have |
| some expression like</p><pre class="programlisting">element.x.y.z.select(t|t.someProp).a</pre><p>you can always embed one of these io functions anywhere such as |
| in</p><pre class="programlisting">element.x.<span class="emphasis"><em>syserr()</em></span>.y.z.select(t|t.someProp.<span class="emphasis"><em>info()</em></span>).a</pre></div><div class="section" title="Controlling the log level"><div class="titlepage"><div><div><h4 class="title"><a name="N124AF"></a>Controlling the log level</h4></div></div></div><p>You may want to control the logging level for the messages which |
| are printed via the logging facility. How this is configured in detail |
| depends on the underlying logging framework. Xpand uses the Apache |
| Commons Logging library, which may dispatches to another logging |
| framework, mostly Log4J.</p><p>To control the logging level exactly for the IO extensions you |
| have to know the category to which the messages are logged to. It is |
| common to use the class names of the classes that use the logger. In |
| the case of the IO extensions this class is |
| <code class="classname">org.eclipse.xtend.util.stdlib.IOExtensions</code> |
| .</p><p>The following example shows a Log4J configuration file which |
| would disable log levels below warning. This example would only work |
| if the properties file is found at the beginning of the classpath. |
| Make sure that the file would be found before any other Log4J |
| configurations on your classpath. The file must be named |
| <code class="filename">log4j.properties</code>.</p><pre class="programlisting">log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender |
| log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout |
| log4j.appender.CONSOLE.layout.ConversionPattern = %p %C{1} %m %n |
| log4j.rootLogger = INFO, CONSOLE |
| # suppress info messages from IOExtensions |
| log4j.logger.org.eclipse.xtend.util.stdlib.IOExtensions=WARN, CONSOLE |
| log4j.additivity.org.eclipse.xtend.util.stdlib.IOExtensions=false</pre></div></div><div class="section" title="Counter extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N124C0"></a>Counter extensions</h3></div></div></div><p>Sometimes it is necessary to have counters within transformation |
| code. The counter extensions enable to initialize, manipulate and |
| retrieve counters.</p><p><span class="emphasis"><em>Extension: |
| </em></span><code class="classname">org::eclipse:xtend:::util::stdlib::counter</code></p><div class="section" title="int counterInc (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N124CA"></a>int counterInc (Object o)</h4></div></div></div><p>Increments a counter.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - A key for this counter. If this function is called with |
| a <code class="code">null</code> argument an anonymous counter is used. If no |
| counter was registered for the key a new counter instance will be |
| created and initialized with 0.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The incremented counter.</p></div><div class="section" title="int counterDec (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N124DD"></a>int counterDec (Object o)</h4></div></div></div><p>Decrements a counter.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - A key for this counter. If this function is called with |
| a <code class="code">null</code> argument an anonymous counter is used. If no |
| counter was registered for the key a new counter instance will be |
| created and initialized with 0.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The decremented counter.</p></div><div class="section" title="int counterReset (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N124F0"></a>int counterReset (Object o)</h4></div></div></div><p>Resets a counter.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - A key for this counter. If this function is called with |
| a <code class="code">null</code> argument an anonymous counter is used. If no |
| counter was registered for the key a new counter instance will be |
| created and initialized with 0.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Allways 0.</p></div><div class="section" title="int counterGet (Object o)"><div class="titlepage"><div><div><h4 class="title"><a name="N12503"></a>int counterGet (Object o)</h4></div></div></div><p>Retrieves the current state of a counter.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>o - A key for this counter. If this function is called with |
| a <code class="code">null</code> argument an anonymous counter is used.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Current counter value.</p></div><div class="section" title="Example"><div class="titlepage"><div><div><h4 class="title"><a name="N12516"></a>Example</h4></div></div></div><pre class="programlisting">«DEFINE CounterExtensionsDemo FOR Object» |
| «FILE "CounterExtensions.txt"» |
| First counter: |
| get : «counterGet()» |
| inc : «counterInc()» |
| inc : «counterInc()» |
| inc : «counterInc()» |
| dec : «counterDec()» |
| Second (named) counter: |
| inc : «counterInc("idx")» |
| inc : «counterInc("idx")» |
| inc : «counterInc("idx")» |
| reset : «counterReset("idx")» |
| inc : «counterInc("idx")» |
| First counter: |
| inc : «counterInc()» |
| |
| «ENDFILE» |
| «ENDDEFINE»</pre><p>This example will create the following output:</p><pre class="programlisting"> First counter: |
| get : 0 |
| inc : 1 |
| inc : 2 |
| inc : 3 |
| dec : 2 |
| Second (named) counter: |
| inc : 1 |
| inc : 2 |
| inc : 3 |
| reset : 0 |
| inc : 1 |
| First counter: |
| inc : 3 </pre></div></div><div class="section" title="Properties extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N12520"></a>Properties extensions</h3></div></div></div><p>You might want to specify configuration values from properties |
| files from your transformation code. The Properties extensions can help |
| you there. Before being able to access the properties through an |
| extension function the properties files must be read and its values |
| stored. This is done through the workflow component |
| <span class="emphasis"><em>PropertiesReader</em></span>, which is described below.</p><p><span class="emphasis"><em>Extension:</em></span> |
| <code class="classname">org::eclipse::xtend::util::stdlib::properties</code></p><div class="section" title="String getProperty (String key)"><div class="titlepage"><div><div><h4 class="title"><a name="N1252E"></a>String getProperty (String key)</h4></div></div></div><p>Retrieves a configuration property.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">o</code> - Property key</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Property value, if defined, else |
| null.</p></div><div class="section" title="Workflow component"><div class="titlepage"><div><div><h4 class="title"><a name="N12540"></a>Workflow component</h4></div></div></div><p>The workflow component PropertiesReader is used to load |
| properties files. It is possible to configure multiple properties |
| files by adding the propertiesFile tag multiple times.</p><div class="table"><a name="N12545"></a><p class="title"><b>Table 1. Workflow component |
| org.eclipse.xtend.util.stdlib.PropertiesReader</b></p><div class="table-contents"><table summary="Workflow component |
| org.eclipse.xtend.util.stdlib.PropertiesReader" border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td>Property</td><td>Type</td><td>Mandatory</td><td>Description</td></tr><tr><td>propertiesFile</td><td>String</td><td>yes</td><td>The properties file to read</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" title="Example"><div class="titlepage"><div><div><h4 class="title"><a name="N1255D"></a>Example</h4></div></div></div><p>Workflow configuration:</p><pre class="programlisting"><component class="org.eclipse.xtend.util.stdlib.PropertiesReader"> |
| <propertiesFile value="src/config1.properties"/> |
| <propertiesFile value="src/config2.properties"/> |
| </component> </pre><p><code class="filename">config1.properties</code>:</p><pre class="programlisting">shapes = box,polygon,ellipse,point</pre><p>Usage in an extension:</p><pre class="programlisting">extension org::eclipse::xtend::util::stdlib::properties; |
| |
| cached List[String] SHAPES () : getProperty("shapes").split(",").trim();</pre></div></div><div class="section" title="Element properties extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N1256E"></a>Element properties extensions</h3></div></div></div><p>This allows you to temporarily associate name-value pairs with any |
| model element.</p><p><span class="emphasis"><em>Extension:</em></span> |
| <code class="classname">org::eclipse::xtend::util::stdlib::elementprops</code></p><p></p><div class="section" title="Void setProperty (Object element, String name, Object value)"><div class="titlepage"><div><div><h4 class="title"><a name="N1257A"></a>Void setProperty (Object element, String name, Object |
| value)</h4></div></div></div><p>Sets the property named <code class="code">name</code> to the value.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">element</code> - The model element</p></li><li class="listitem"><p><code class="code">name</code> - Property name</p></li><li class="listitem"><p><code class="code">element</code> - The property value</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Nothing.</p></div><div class="section" title="Object getProperty (Object element, String name)"><div class="titlepage"><div><div><h4 class="title"><a name="N12599"></a>Object getProperty (Object element, String name)</h4></div></div></div><p>Retrieves a dynamic property from an element.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">element</code> - The model element</p></li><li class="listitem"><p><code class="code">name</code> - Property name</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The property value.</p></div></div><div class="section" title="Issues extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N125B0"></a>Issues extensions</h3></div></div></div><p>In template code there is no direct access to the Issues instance |
| of the workflow's context possible. The Issues extensions help to report |
| warnings and errors to the Issues instance during transformation.</p><p>This should not encourage you to use constraint checking and |
| generally raise errors directly from within the transformations. |
| However, sometimes it is sensible and useful to be able to do |
| that.</p><p><span class="emphasis"><em>Extension: |
| </em></span><code class="classname">org::eclipse::xtend::util::stdlib::issues</code></p><div class="section" title="String reportWarning (String message)"><div class="titlepage"><div><div><h4 class="title"><a name="N125BC"></a>String reportWarning (String message)</h4></div></div></div><p>Reports a warning message to the workflow context.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">message</code> - A message</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The message.</p></div><div class="section" title="String reportWarning (Object object, String message)"><div class="titlepage"><div><div><h4 class="title"><a name="N125CE"></a>String reportWarning (Object object, String message)</h4></div></div></div><p>Reports a warning message and the qualified name of a context |
| object to the workflow context.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">object</code> - A context objectt</p></li><li class="listitem"><p><code class="code">message</code> - A message</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The message.</p></div><div class="section" title="String reportError (String message)"><div class="titlepage"><div><div><h4 class="title"><a name="N125E5"></a>String reportError (String message)</h4></div></div></div><p>Reports a error message to the workflow context.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">message</code> - A message</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The message.</p></div><div class="section" title="String reportError (Object object, String message)"><div class="titlepage"><div><div><h4 class="title"><a name="N125F7"></a>String reportError (Object object, String message)</h4></div></div></div><p>Reports a error message and the qualified name of a context |
| object to the workflow context.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">object</code> - A context object</p></li><li class="listitem"><p><code class="code">message</code> - A message</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The message.</p></div><div class="section" title="Workflow component"><div class="titlepage"><div><div><h4 class="title"><a name="N1260E"></a>Workflow component</h4></div></div></div><p>The Issues extensions require that the workflow component |
| <code class="classname">org.eclipse.xtend.util.stdlib.ExtIssueReporter</code> |
| is configured in the workflow before calling the extensions. The |
| purpose of this component is make the workflow's Issues instance |
| available for the extensions.</p><p>The <code class="classname">ExtIssueReporter</code> component does not |
| have any properties.</p></div><div class="section" title="Example"><div class="titlepage"><div><div><h4 class="title"><a name="N1261B"></a>Example</h4></div></div></div><p>Workflow configuration:</p><pre class="programlisting"><?xml version="1.0"?> |
| <workflow> |
| ... |
| <component class="xpand.util.stdlib.ExtIssueReporter"/></pre><p>Using from Xtend:</p><pre class="programlisting">import metamodel; |
| extension org::eclipse::xtend::util::stdlib::issues; |
| |
| demo (Model this) : |
| issuesExtensionsDemo() |
| ; |
| |
| issuesExtensionsDemo () : |
| reportWarning("Reporting a warn message from Xtend to the workflow");</pre><p>Console output:</p><pre class="programlisting">INFO WorkflowRunner running workflow: workflow/generator.mwe |
| ... |
| ... |
| INFO CompositeComponent ExtIssueReporter: setting up issue logging from |
| within .ext and .xpt files |
| INFO WorkflowRunner workflow completed in 1101ms! |
| WARN WorkflowRunner Reporting a warn message from Xtend to the workflow</pre></div></div><div class="section" title="Naming extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N1262A"></a>Naming extensions</h3></div></div></div><p>The Naming extensions are only usable with EMF models. This one |
| helps with names, qualified names and namespaces. A qualified name is |
| defined as the seuqence of primitive names of the containment hierarchy |
| of an element, seperated by a dot (e.g. java.lang.String). In order for |
| this to work, model elements are expected to have a name attribute of |
| type EString.<sup>[<a href="#ftn.N1262F" name="N1262F" class="footnote">9</a>]</sup></p><p><span class="emphasis"><em>Extension: |
| </em></span><code class="classname">org::eclipse::xtend::util::stdlib::naming |
| </code></p><div class="section" title="String namespace (Object this)"><div class="titlepage"><div><div><h4 class="title"><a name="N12637"></a>String namespace (Object this)</h4></div></div></div><p>Returns the namespace, i.e. the qualified name minus the name of |
| the element itself.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">this</code> - A model element</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The qualified namespace name of |
| the element.</p></div><div class="section" title="String qualifiedName (Object this)"><div class="titlepage"><div><div><h4 class="title"><a name="N12649"></a>String qualifiedName (Object this)</h4></div></div></div><p>Returns the qualified name (dot separated) of an element by |
| evaluating its containment hierarchy.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">this</code> - A model element</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The qualified name of the |
| element.</p></div><div class="section" title="String loc (Object this)"><div class="titlepage"><div><div><h4 class="title"><a name="N1265B"></a>String loc (Object this)</h4></div></div></div><p>Tries to build a useful description of an element in the model; |
| very useful for error reporting.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">this</code> - A model element</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Location information about the |
| element.</p></div><div class="section" title="Object findByName (Collection candidates, String name)"><div class="titlepage"><div><div><h4 class="title"><a name="N1266D"></a>Object findByName (Collection candidates, String name)</h4></div></div></div><p>Searches the candidates for an element with a specific |
| name.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">candidates</code> - A collection of model |
| elements</p></li><li class="listitem"><p><code class="code">name</code> - The searched element name</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The searched element or null if no |
| element with that name is contained in the candidates |
| collection.</p></div></div><div class="section" title="Globalvar extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N12684"></a>Globalvar extensions</h3></div></div></div><p>Sometimes you might want to share information within a |
| transformation process. One alternative is the use of GLOBALVAR |
| expressions, but this needs that the variables are configured in the |
| workflow. The Globalvar extensions help to store and retrieve objects |
| within a transformation process.</p><p><span class="emphasis"><em>Extension:</em></span><code class="classname"> |
| org::eclipse::xtend::util::stdlib::globalvar</code></p><div class="section" title="Example"><div class="titlepage"><div><div><h4 class="title"><a name="N1268E"></a>Example</h4></div></div></div><p>Usage in Xtend:</p><pre class="programlisting">import metamodel; |
| extension org::eclipse::xtend::util::stdlib::io; |
| extension org::eclipse::xtend::util::stdlib::globalvar; |
| |
| demo (Model this) : |
| globalvarExtensionsDemo1() -> |
| globalvarExtensionsDemo2() |
| ; |
| |
| globalvarExtensionsDemo1 () : |
| "Storing global var...".info() -> |
| storeGlobalVar("msg", "Xpand is cool stuff!"); |
| |
| globalvarExtensionsDemo2 () : |
| ("Getting message from global var: "+getGlobalVar("msg")).info();</pre><p>Console output:</p><pre class="programlisting">INFO IOExtensions Storing global var... |
| INFO IOExtensions Getting message from global var: Xpand is cool stuff!</pre><p>This a simple example storing a string, but of course you can |
| store the result of any expression this way.</p></div></div><div class="section" title="Cloning extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N1269B"></a>Cloning extensions</h3></div></div></div><p>The cloning utilities help you to clone a model element and all |
| its children. The <code class="code">clone(Object)</code> function clones a single |
| object and its children, whereas the <code class="code">clone(List)</code> clones a |
| list of elements. The semantics of cloning is as follows:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>the object passed in as a parameter is duplicated</p></li><li class="listitem"><p>all objects referenced via containment references are also |
| duplicated, recursively</p></li><li class="listitem"><p>the values of the attributes are duplicated</p></li><li class="listitem"><p>non-containing references to other objects are copied while |
| the target is not cloned (a reference to the original is created in |
| the new object)</p></li></ul></div><p><span class="emphasis"><em>Extension:</em></span> |
| <code class="classname">org::eclipse::xtend::util::stdlib::cloning</code></p><div class="section" title="Object clone (Object original)"><div class="titlepage"><div><div><h4 class="title"><a name="N126B9"></a>Object clone (Object original)</h4></div></div></div><p>Clones an object.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">original</code> - The object that should be |
| cloned.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The cloned object.</p></div><div class="section" title="List clone (List l)"><div class="titlepage"><div><div><h4 class="title"><a name="N126CB"></a>List clone (List l)</h4></div></div></div><p>Clones a list of objects.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">l</code> - Source list.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The list of cloned objects.</p></div></div><div class="section" title="Cross references extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N126DD"></a>Cross references extensions</h3></div></div></div><p>Sometimes there is the need to find objects that reference a |
| specific object. This extension helps to solve this recurring task. This |
| extension can only be used for EMF based models.</p><p><span class="emphasis"><em>Extension: |
| </em></span><code class="classname">org::eclipse::xtend::util::stdlib::crossref</code></p><div class="section" title="List[EObject] getReferencingObjects(EObject target)"><div class="titlepage"><div><div><h4 class="title"><a name="N126E7"></a>List[EObject] getReferencingObjects(EObject target)</h4></div></div></div><p>Retrieves objects that reference a given object.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">target</code> - The target object.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> A list of objects referencing the |
| target.</p></div><div class="section" title="Example"><div class="titlepage"><div><div><h4 class="title"><a name="N126F9"></a>Example</h4></div></div></div><p>Usage in Xtend:</p><pre class="programlisting">extension org::eclipse::xtend::util::stdlib::crossref; |
| crossRefDemo (Model this) : |
| eAllContents.typeSelect(Datatype).dumpCrossReferences(); |
| |
| dumpCrossReferences (Datatype this) : |
| ("Number of cross references to datatype "+name+":" |
| + getReferencingObjects().size) |
| .info() |
| ;</pre><p>Console output:</p><pre class="programlisting">INFO IOExtensions Number of cross references to datatype Integer:1 |
| INFO IOExtensions Number of cross references to datatype String:4</pre></div></div><div class="section" title="UID extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N12704"></a>UID extensions</h3></div></div></div><p>Often it is required to create and retrieve unique identifiers for |
| objects through the transformation process. The UID extensions provide a |
| simple mechanism for this task. Unique identifiers are calculated from |
| the current system time plus an internal counter. The extensions |
| therefore only guarantee that the identifier stays the same within one |
| workflow execution, but will change through different runs. If you need |
| to have unique identifiers that stay the same over every generation run |
| (e.g. for Protected Regions Ids) then you need another mechanism.</p><p>If you are loading the model that assigns IDs to |
| <code class="classname">EObject</code> (only for EMF based models) the |
| <code class="methodname">xmlId()</code> function will be useful. Especially |
| when using UML2 models this function will return a unique and |
| non-changing identifier for objects.</p><p><span class="emphasis"><em>Extension:</em></span> |
| <code class="classname">org::eclipse::xtend::util::stdlib::uid</code></p><div class="section" title="cached String uid( Object o )"><div class="titlepage"><div><div><h4 class="title"><a name="N12717"></a>cached String uid( Object o )</h4></div></div></div><p>Retrieves an unique identifier for an object. Creates a new one |
| on first access.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">o</code> - A model element or other object.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The UID for this object</p></div><div class="section" title="String createUID( Object o )"><div class="titlepage"><div><div><h4 class="title"><a name="N12729"></a>String createUID( Object o )</h4></div></div></div><p>Creates a unique identifier for an object.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">o</code> - A model element or other object.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> A newly created UID for this |
| object.</p></div><div class="section" title="String xmlId (ecore::EObject o)"><div class="titlepage"><div><div><h4 class="title"><a name="stdlib_uid_xmlid"></a>String xmlId (ecore::EObject o)</h4></div></div></div><p>Retrieves an object's identifier. The object must be read from a |
| XMLResource.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">o</code> - An object.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The object's id. Returns null if |
| the object was not load from a XMLResource.</p></div></div><div class="section" title="Mixin extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N1274E"></a>Mixin extensions</h3></div></div></div><p>These utilities help with mixin models. Mixin models are typically |
| simple models that provide additional information about model elements |
| in a source model of a transformation. They can be seen as |
| annotations.</p><p>These utilities expect that the mixin models have a very specific |
| structure: A root element, and then any subtree, where the elements have |
| a name attribute. Here's an example:</p><div class="figure"><a name="N12755"></a><p class="title"><b>Figure 1. Mixin model example</b></p><div class="figure-contents"><div class="screenshot"><div class="mediaobject"><img src="images/stdlib/mixinmodel.png" width="432" alt="Mixin model example"></div></div></div></div><br class="figure-break"><p>The mixin elements are |
| <code class="classname">ControllingServiceRefSpec</code> and |
| <code class="classname">BundleSpec</code>. They are owned by the root element, |
| <code class="classname">Cbd2OsgiMixin</code>. The name is expected to contain |
| the qualified name of the element the annotation refers to. Once the |
| model is set up like this, and made available to a transformation using |
| the workflow's GLOBALVAR facilities, you can then use the extension |
| functions.</p><p>Extension: org::eclipse::xtend::util::stdlib::mixin</p><div class="section" title="Object getMandatoryMixin( Object mixinModel, Object ctx, xpand2::Type t )"><div class="titlepage"><div><div><h4 class="title"><a name="N1276D"></a>Object getMandatoryMixin( Object mixinModel, Object ctx, |
| xpand2::Type t )</h4></div></div></div><p>Returns the corresponding mixin element for the context object; |
| the mixin must be of type t and its name attribute must correspond to |
| the qualified name of the context. If none is found, a workflow ERROR |
| is raised and a null object is returned (so you can call additional |
| operations on it without getting a null evaluation error).</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">mixinModel</code> - The root element of the mixin |
| model.</p></li><li class="listitem"><p><code class="code">ctx</code> - The context object.</p></li><li class="listitem"><p><code class="code">t</code> - The type of the mixin model element.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The mixin model element |
| corresponding to ctx.</p></div><div class="section" title="Object getOptionalMixin( Object mixinModel, Object ctx, xpand2::Type t )"><div class="titlepage"><div><div><h4 class="title"><a name="N12789"></a>Object getOptionalMixin( Object mixinModel, Object ctx, |
| xpand2::Type t )</h4></div></div></div><p>Same as getMandatoryMixin(), but does not raise an error in case |
| nothing is found.</p></div></div><div class="section" title="Tracing extensions"><div class="titlepage"><div><div><h3 class="title"><a name="N1278E"></a>Tracing extensions</h3></div></div></div><p>The tracing extensions allow to create trace paths during your |
| model transformations. This is done by creating a trace model which |
| holds references from source to target elements. Traces must be added |
| explicitly to the transformation code.</p><p><span class="emphasis"><em>Extension:</em></span> |
| <code class="classname">org::eclipse::xtend::util::stdlib::tracing</code></p><div class="section" title="Void createTrace( Object from, Object to, String kind, String backKind )"><div class="titlepage"><div><div><h4 class="title"><a name="N12799"></a>Void createTrace( Object from, Object to, String kind, String |
| backKind )</h4></div></div></div><p>Creates a trace between two elements.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">from</code> - Source element.</p></li><li class="listitem"><p><code class="code">to</code> - Target element.</p></li><li class="listitem"><p><code class="code">kind</code> - Name for the trace from source to |
| target.</p></li><li class="listitem"><p><code class="code">backkind</code> - Name for the trace from target back |
| to source.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Nothing.</p></div><div class="section" title="Void createTrace( Object from, Object to, String kind)"><div class="titlepage"><div><div><h4 class="title"><a name="N127BA"></a>Void createTrace( Object from, Object to, String kind)</h4></div></div></div><p>Creates a trace between two elements.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">from</code> - Source element.</p></li><li class="listitem"><p><code class="code">to</code> - Target element.</p></li><li class="listitem"><p><code class="code">kind</code> - Name for the trace from source to |
| target.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> Nothing.</p></div><div class="section" title="Void clearTrace()"><div class="titlepage"><div><div><h4 class="title"><a name="N127D6"></a>Void clearTrace()</h4></div></div></div><p>Clears all traces.</p><p><span class="emphasis"><em>Parameters: </em></span> none</p><p><span class="emphasis"><em>Returns:</em></span> Nothing.</p></div><div class="section" title="Object getSingleTraceTarget( Object from, String kind )"><div class="titlepage"><div><div><h4 class="title"><a name="N127E3"></a>Object getSingleTraceTarget( Object from, String kind )</h4></div></div></div><p>Finds the target of a trace. This function will report an error |
| if no trace for the source element to the target of the specified kind |
| can be found.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">from</code> - Source element.</p></li><li class="listitem"><p><code class="code">kind</code> - Trace kind name.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> The target element of that |
| trace.</p></div><div class="section" title="Boolean hasTrace( Object from, String kind )"><div class="titlepage"><div><div><h4 class="title"><a name="N127FA"></a>Boolean hasTrace( Object from, String kind )</h4></div></div></div><p>Proves if a trace of a specific kind exists for some |
| element.</p><p><span class="emphasis"><em>Parameters: </em></span></p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="code">from</code> - Source element.</p></li><li class="listitem"><p><code class="code">kind</code> - Trace kind name.</p></li></ul></div><p><span class="emphasis"><em>Returns:</em></span> true, if a trace of that kind |
| exists for the element.</p></div></div></div><div class="section" title="Stdlib workflow components"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12811"></a>Stdlib workflow components</h2></div></div></div><p>Besides the extensions described in the previous section Xpand's |
| Stdlib provides some workflow components.</p><div class="section" title="SystemCommand"><div class="titlepage"><div><div><h3 class="title"><a name="N12816"></a>SystemCommand</h3></div></div></div><p>This component executes a system command<a name="N1281B" class="indexterm"></a>.</p><div class="table"><a name="N1281F"></a><p class="title"><b>Table 2. Workflow component |
| org.eclipse.xtend.util.stdlib.SystemCommand</b></p><div class="table-contents"><table summary="Workflow component |
| org.eclipse.xtend.util.stdlib.SystemCommand" border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th align="center">Property</th><th align="center">Type</th><th align="center">Mandatory</th><th align="center">Description</th></tr></thead><tbody><tr><td>command</td><td>String</td><td>yes</td><td>The command to execute.</td></tr><tr><td>directory</td><td>String</td><td>no</td><td>Execution directory.</td></tr><tr><td>arg</td><td>String</td><td>no</td><td>(multiple) command arguments</td></tr><tr><td>env</td><td>String</td><td>no</td><td>(multiple) additional environment entries. Format: |
| [key],[value]</td></tr></tbody></table></div></div><br class="table-break"><p><span class="bold"><strong>Example:</strong></span></p><pre class="programlisting"><component class="org.eclipse.xtend.util.stdlib.SystemCommand"> |
| <directory value="src-gen"/> |
| <command value="sh"/> |
| <arg value="processdot.sh"/> |
| </component></pre><p><span class="bold"><strong>Console output:</strong></span></p><pre class="programlisting">1639 INFO - Running command '[sh, processdot.sh]' in directory [absolutepath] ... |
| 1667 INFO - processing shape_box.dot ... |
| 2597 INFO - processing shape_polygon.dot ... |
| ... |
| 3564 INFO - Execution of command was successful.</pre><p>Windows tip:</p><p>When executing a command on windows this is typically done with |
| the cmd as command value. It is important that the command terminates, |
| therefore the argument /c must be appended as arg value.<sup>[<a href="#ftn.N1286F" name="N1286F" class="footnote">10</a>]</sup></p></div><div class="section" title="SlotCopier"><div class="titlepage"><div><div><h3 class="title"><a name="N12879"></a>SlotCopier<a name="N1287C" class="indexterm"></a></h3></div></div></div><p>This component copies an element from one slot to another. The |
| slot content is not cloned.</p><div class="table"><a name="N12882"></a><p class="title"><b>Table 3. Workflow component |
| org.eclipse.xtend.util.stdlib.SlotCopier</b></p><div class="table-contents"><table summary="Workflow component |
| org.eclipse.xtend.util.stdlib.SlotCopier" border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th align="center">Property</th><th align="center">Type</th><th align="center">Mandatory</th><th align="center">Description</th></tr></thead><tbody><tr><td>fromSlot</td><td>String</td><td>yes</td><td>Source slot name.</td></tr><tr><td>toSlot</td><td>String</td><td>yes</td><td>Destination slot name.</td></tr><tr><td>removeTopLevelList</td><td>boolean</td><td>no</td><td>If true the source slot must contain a list and the top |
| level list is removed (i.e. the first element from the list is |
| copied to the destination slot), otherwise it is not |
| removed.</td></tr></tbody></table></div></div><p><br class="table-break"><span class="bold"><strong>Example:</strong></span></p><pre class="programlisting"><component class="org.eclipse.xtend.util.stdlib.SlotCopier"> |
| <fromSlot value="model"/> |
| <toSlot value="target"/> |
| </component></pre><p><span class="bold"><strong>Console output:</strong></span></p><pre class="programlisting">INFO SlotCopier copying org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1fdbef |
| (eClass: org.eclipse.emf.ecore.impl.EClassImpl@fc5b01 |
| (name: Model) (instanceClassName: null) (abstract: false, interface: false)) |
| [org.eclipse.emf.ecore.impl.DynamicEObjectImpl]</pre></div><div class="section" title="SlotListAdder"><div class="titlepage"><div><div><h3 class="title"><a name="N128C4"></a>SlotListAdder<a name="N128C7" class="indexterm"></a></h3></div></div></div><p>This component copies an element from one slot to a list contained |
| in another slot.</p><div class="table"><a name="N128CC"></a><p class="title"><b>Table 4. Workflow component |
| org.eclipse.xtend.util.stdlib.SlotListAdder</b></p><div class="table-contents"><table summary="Workflow component |
| org.eclipse.xtend.util.stdlib.SlotListAdder" border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th align="center">Property</th><th align="center">Type</th><th align="center">Mandatory</th><th align="center">Description</th></tr></thead><tbody><tr><td>modelSlot</td><td>String</td><td>yes</td><td>Source slot name.</td></tr><tr><td>listSlot</td><td>String</td><td>yes</td><td>Target slot name. This slot contains a list of |
| elements.</td></tr><tr><td>uniqueNames</td><td>boolean</td><td>no</td><td>If true, names have to be unique, otherwise not. Requires |
| that modelSlot contains an EObject.</td></tr></tbody></table></div></div><br class="table-break"><p><span class="bold"><strong>Example:</strong></span></p><p>This example adds the content of slot 'model' to the slot |
| 'targetList'. The slot 'targetList' does not contain anything at the |
| time of execution.</p><pre class="programlisting"><component class="org.eclipse.xtend.util.stdlib.SlotListAdder"> |
| <modelSlot value="model"/> |
| <listSlot value="targetList"/> |
| </component></pre><p><span class="bold"><strong>Console output:</strong></span></p><pre class="programlisting">INFO CompositeComponent SlotListAdder: adding contents of slot 'model' to the list of |
| stuff in 'targetList' |
| ... |
| ... |
| INFO WorkflowRunner workflow completed in 1503ms! |
| WARN WorkflowRunner 'targetList' is empty, creating a new list. |
| [org.eclipse.xtend.util.stdlib.SlotListAdder@7536e7]</pre><p>Note that the warn messages will appear after the workflow |
| finished, since they are reported as a workflow warn issue.</p></div><div class="section" title="SlotPrinter"><div class="titlepage"><div><div><h3 class="title"><a name="N12913"></a>SlotPrinter<a name="N12916" class="indexterm"></a></h3></div></div></div><p>This component prints a workflow context slot content to the log. |
| This can be useful for debugging purposes.</p><div class="table"><a name="N1291B"></a><p class="title"><b>Table 5. Workflow component |
| org.eclipse.xtend.util.stdlib.SlotPrinter</b></p><div class="table-contents"><table summary="Workflow component |
| org.eclipse.xtend.util.stdlib.SlotPrinter" border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th align="center">Property</th><th align="center">Type</th><th align="center">Mandatory</th><th align="center">Description</th></tr></thead><tbody><tr><td>slotName</td><td>String</td><td>yes</td><td>The name of a slot whose content should be |
| dumped.</td></tr><tr><td>message</td><td>String</td><td>no</td><td>An optional message that will be prefixed to the log |
| output.</td></tr><tr><td>level</td><td>String</td><td>no</td><td>The log level for the message. Valid values are TRACE, |
| DEBUG, INFO, WARN.</td></tr></tbody></table></div></div><br class="table-break"><p><span class="bold"><strong>Example:</strong></span></p><pre class="programlisting"><component class="org.eclipse.xtend.util.stdlib.SlotPrinter"> |
| <slotName value="model"/> |
| <message value="DUMP"/> |
| <level value="INFO"/> |
| </component></pre><p><span class="bold"><strong>Console output:</strong></span></p><pre class="programlisting">INFO SlotPrinter DUMP: (slot: model)org.eclipse.emf.ecore.impl.DynamicEObjectImpl@d22ddb |
| (eClass: org.eclipse.emf.ecore.impl.EClassImpl@fe0ce9 (name: Model) (instanceClassName: null) |
| (abstract: false, interface: false))</pre></div></div><div class="footnotes"><br><hr align="left" width="100"><div class="footnote"><p><sup>[<a href="#N1262F" name="ftn.N1262F" class="para">9</a>] </sup>It is intended that the uml2ecore utility can add such a name |
| attribute to every meta class automatically.</p></div><div class="footnote"><p><sup>[<a href="#N1286F" name="ftn.N1286F" class="para">10</a>] </sup>See <a class="ulink" href="http://www.ss64.com/nt/cmd.html" target="_new">http://www.ss64.com/nt/cmd.html</a>, |
| <a class="ulink" href="http://www.java-forum.org/de/viewtopic.php?p=469059" target="_new">http://www.java-forum.org/de/viewtopic.php?p=469059</a></p></div></div></div><div class="chapter" title="Chapter 5. Xpand Eclipse Integration"><div class="titlepage"><div><div><h2 class="title"><a name="eclipse_integration"></a>Chapter 5. Xpand Eclipse Integration</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#eclipse_integration_introduction">Introduction</a></span></dt><dt><span class="section"><a href="#eclipse_integration_installation">Installation</a></span></dt><dt><span class="section"><a href="#eclipse_integration_overview">Overview</a></span></dt><dt><span class="section"><a href="#eclipse_integration_file_decorations">File decorations</a></span></dt><dt><span class="section"><a href="#eclipse_integration_editors">Editors</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_editors_syntax_coloring">Syntax coloring</a></span></dt><dt><span class="section"><a href="#eclipse_integration_editors_code_completion">Code completion</a></span></dt><dt><span class="section"><a href="#eclipse_integration_editors_xpand_tag_delimiter"><span class="emphasis"><em>Xpand</em></span> tag delimiter creation support</a></span></dt></dl></dd><dt><span class="section"><a href="#eclipse_integration_preference_pages">Preference pages</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_preference_pages_meta_model_contributors">Metamodel contributors</a></span></dt><dt><span class="section"><a href="#eclipse_integration_preference_pages_global_preferences">Global preferences</a></span></dt><dt><span class="section"><a href="#eclipse_integration_preference_pages_preferences_per_project">Preferences per project</a></span></dt></dl></dd><dt><span class="section"><a href="#eclipse_integration_xpand_nature_builder">Xpand Nature and Xpand Builder</a></span></dt><dd><dl><dt><span class="section"><a href="#eclipse_integration_xpand_nature_builder_problem_markers">Problem markers</a></span></dt></dl></dd><dt><span class="section"><a href="#eclipse_integration_running_a_workflow">Running a workflow</a></span></dt></dl></div><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_introduction"></a>Introduction</h2></div></div></div><p>This document describes the various functionalities that the Xpand |
| plugins contribute to the Eclipse installation. It is intended as user |
| instruction for the work with Eclipse. You need to read other |
| documentation to understand the Xpand framework itself.</p></div><div class="section" title="Installation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_installation"></a>Installation</h2></div></div></div><p>It is assumed that you already have installed the Xpand core and the |
| Xpand UI feature from the update site as described in the |
| <span class="emphasis"><em>Installation documentation</em></span>.</p></div><div class="section" title="Overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_overview"></a>Overview</h2></div></div></div><p>The Xpand UI plugins provide editors for the different languages and |
| a launch shortcut to start workflow files. Let us first have a look at the |
| different Xpand specific files.</p></div><div class="section" title="File decorations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_file_decorations"></a>File decorations</h2></div></div></div><p>When you open Eclipse and import a project into the workspace you |
| can see several file decorating images.</p><div class="informaltable"><table border="0"><colgroup><col width=""><col width="" align="left"></colgroup><tbody><tr valign="top"><td align="left" valign="top"><p>There are specific images for:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Workflow files (<code class="filename">.mwe</code> |
| extension)</p></li><li class="listitem"><p><span class="emphasis"><em>Xpand2</em></span> templates (<code class="filename">.xpt |
| </code>extension)</p></li><li class="listitem"><p>Extension files (<code class="filename">.ext</code> |
| extension)</p></li><li class="listitem"><p><span class="emphasis"><em>Check</em></span> constraints |
| (<code class="filename">.chk</code> extension)</p></li></ul></div></td><td align="left" valign="top"><div class="mediaobject"><img src="images/eclipse_integration/fileImages.png" width="NaN"></div></td></tr></tbody></table></div></div><div class="section" title="Editors"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_editors"></a>Editors</h2></div></div></div><p>When you double-click on one of the above mentioned file types, |
| special editors will open that provide appropriate syntax coloring.</p><div class="section" title="Syntax coloring"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_editors_syntax_coloring"></a>Syntax coloring</h3></div></div></div><p>Here are examples for the <span class="emphasis"><em>Xpand</em></span> editor: |
| </p><div class="mediaobject"><img src="images/eclipse_integration/xpandCodeHighlighting.jpg"></div><p>for the Extensions editor: </p><div class="mediaobject"><img src="images/eclipse_integration/xtendCodeHighlighting.jpg"></div><p>and for <span class="emphasis"><em>Check</em></span> editor: </p><div class="mediaobject"><img src="images/eclipse_integration/checkCodeHighlighting.jpg"></div></div><div class="section" title="Code completion"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_editors_code_completion"></a>Code completion</h3></div></div></div><p>The Editors provide extensive code completion support by pressing |
| <span class="keycap"><strong>Ctrl + Space</strong></span> similar to what is known from the Java |
| editor. Available types, properties, and operation, as well as |
| extensions from <code class="filename">.ext</code> files will be found. The |
| <span class="emphasis"><em>Xpand</em></span> editor provides additionally support for the |
| <span class="emphasis"><em>Xpand</em></span> language statements. </p><div class="mediaobject"><img src="images/eclipse_integration/codeCompletion.jpg"></div></div><div class="section" title="Xpand tag delimiter creation support"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_editors_xpand_tag_delimiter"></a><span class="emphasis"><em>Xpand</em></span> tag delimiter creation support</h3></div></div></div><p>In the <span class="emphasis"><em>Xpand</em></span> editor there is an additional |
| keystroke available to create the opening and closing tag brackets, the |
| <span class="foreignphrase"><em class="foreignphrase">guillemets</em></span> ("«" and "»"). </p><div class="variablelist"><dl><dt><span class="term"><span class="keycap"><strong>Ctrl + <</strong></span></span></dt><dd><p>creates "«"</p></dd><dt><span class="term"><span class="keycap"><strong>Ctrl + ></strong></span></span></dt><dd><p>creates "»"</p></dd></dl></div></div></div><div class="section" title="Preference pages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_preference_pages"></a>Preference pages</h2></div></div></div><div class="section" title="Metamodel contributors"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_preference_pages_meta_model_contributors"></a>Metamodel contributors</h3></div></div></div><p>Xpand supports several types of meta-metamodels.</p><p>From older versions, the classic UML metamodels may be known. |
| Currently also JavaBeans metamodels and EMF based metamodels are |
| supported out of the box.</p><p>Additional metamodel contributors can be registered through an |
| extension point.</p><p>The editors need to know with what kind of metamodels you are |
| working. Therefore, one can configure the metamodel contributors on |
| workspace and on project level.</p></div><div class="section" title="Global preferences"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_preference_pages_global_preferences"></a>Global preferences</h3></div></div></div><p>If you work always with the same type of metamodels, you can |
| specify the metamodel contributors in the global preference page. It is |
| available under Windows --> Preferences in the |
| <span class="emphasis"><em>Xtend/Xpand</em></span> section.</p></div><div class="section" title="Preferences per project"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_preference_pages_preferences_per_project"></a>Preferences per project</h3></div></div></div><p>In the project property page there is also an |
| <span class="emphasis"><em>Xtend/Xpand</em></span> section available.</p><p>Therein you can enable the Xtend/Xpand nature (see below) |
| and set project specific metamodel contributor settings. </p><div class="mediaobject"><img src="images/eclipse_integration/projectProperties.png"></div></div></div><div class="section" title="Xpand Nature and Xpand Builder"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_xpand_nature_builder"></a>Xpand Nature and Xpand Builder</h2></div></div></div><p>You have seen in the last screenshot that you can switch the |
| <span class="emphasis"><em>Xpand</em></span> nature on. If you do so, you enable analyzer |
| support for all Xpand specific file types in that project.</p><div class="section" title="Problem markers"><div class="titlepage"><div><div><h3 class="title"><a name="eclipse_integration_xpand_nature_builder_problem_markers"></a>Problem markers</h3></div></div></div><p>During the build process, all found problems are marked in the |
| editors as well as listed in the <span class="emphasis"><em>Problems</em></span> view. |
| </p><div class="mediaobject"><img src="images/eclipse_integration/problemDisplay.jpg"></div><p>In the current implementation analyzes take place when |
| <span class="emphasis"><em>Eclipse</em></span> runs an incremental or full build. That |
| means, problem markers are actualized when a file is saved, for |
| instance. If you are in doubt about the actuality of problem markers, |
| you should clean your project and let it rebuild again.</p><p>Note that if you change signatures of e.g. extensions the |
| referencing artifacts (Xpand templates, etc.) are not analyzed |
| automatically.</p></div></div><div class="section" title="Running a workflow"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse_integration_running_a_workflow"></a>Running a workflow</h2></div></div></div><p>You can start a workflow by right clicking on a workflow file |
| <code class="filename">(*.mwe)</code> and selecting <span class="guimenu">Run As</span> → <span class="guimenuitem">MWE workflow</span>. </p><div class="mediaobject"><img src="images/eclipse_integration/workflowStart.png"></div><p>Because it is a normal launch configuration, you could run or even |
| debug it using the normal Eclipse functionality.</p></div></div><div class="chapter" title="Chapter 6. Incremental Generation"><div class="titlepage"><div><div><h2 class="title"><a name="incrementalGeneration"></a>Chapter 6. Incremental Generation</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#incrementalGeneration_background">Technical Background</a></span></dt><dt><span class="section"><a href="#incrementalGeneration_usage">Using Incremental Generation</a></span></dt><dd><dl><dt><span class="section"><a href="#incrementalGeneration_usage_facade">The Incremental Generation Facade</a></span></dt><dt><span class="section"><a href="#incrementalGeneration_usage_callback">The Incremental Generation Callback</a></span></dt></dl></dd><dt><span class="section"><a href="#incrementalGeneration_notes">Additional Notes</a></span></dt><dd><dl><dt><span class="section"><a href="#incrementalGeneration_limitations">Limitations</a></span></dt><dt><span class="section"><a href="#incrementalGeneration_performance">Performance Considerations</a></span></dt></dl></dd></dl></div><p> |
| As projects become larger, so typically do their models. However, the larger |
| the models are, the longer the code generation process takes. In a mature |
| project, a developer typically changes only a small part of a large model. |
| Performing a full code generation process for the whole model slows down the |
| development cycle considerably due to various factors: |
| |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> |
| The whole model must be traversed, and each statement in the Xpand |
| templates must be executed. The larger the model is and the more Xpand |
| templates you have, the higher the negative impact is. |
| </li><li class="listitem"> |
| All generated files are written to disk. The I/O operation itself is |
| one major contributor to the overall elapsed time. What's more, files |
| are typically post-processed by beautifiers, which is another time |
| consuming operation. If you are working with protected regions, the |
| impact is even more dramatic. |
| </li><li class="listitem"> |
| Since every file has a new timestamp after code generation, typically |
| a compiler will pick up these new files and start compilation, which |
| adds more CPU and I/O cycles to the process. |
| </li></ul></div><p> |
| |
| Considering that for a small change in the model only a fraction of the |
| generated files actually do change their contents, performing a full |
| generation is obviously a waste of time. |
| </p><p> |
| Beginning with the Helios release train (Eclipse 3.6, Xpand 0.8), Xpand |
| now ships with an incremental generation facility. This works very similar |
| to the incremental Java compiler in Eclipse. It detects which parts of a |
| model have changed since the last generation process. It then |
| determines which files need to be generated due to that change and which |
| are unaffected by it. Only the former are the regenerated, while the |
| latter remain untouched. |
| </p><p> |
| The following sections explain how this incremental generation feature |
| works and how you can use it. |
| </p><div class="section" title="Technical Background"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="incrementalGeneration_background"></a>Technical Background</h2></div></div></div><p> |
| The key to incremental generation lies in knowing which element in a model |
| was used to generate which file. This information can easily be computed |
| during generation, by tracking which parts of the model are |
| accessed in the context of any given |
| <code class="code">«FILE»</code> statement. A callback for the |
| Xpand generator does this job and builds up a so-called |
| <span class="emphasis"><em>trace model</em></span> on-the-fly. |
| </p><p> |
| The second important information is the actual change that has occurred |
| in a model. There are basically two ways to compute this. One is to |
| attach a change listener when editing the model and capture the change |
| as it happens. The other way is to keep a backup copy of the model and |
| compare the old version with the current version to compute the change. |
| See <a class="xref" href="#incrementalGeneration_performance" title="Performance Considerations">the section called “Performance Considerations”</a> |
| for pros and cons of each of the two ways. In either |
| case, the result is a so-called <span class="emphasis"><em>diff model</em></span>. |
| </p><p> |
| When we know which parts of a model have changed, and we also know which |
| files have been produced based upon these parts of the model, we can then |
| skip the generation of all other files, thus performing incremental |
| generation. |
| </p></div><div class="section" title="Using Incremental Generation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="incrementalGeneration_usage"></a>Using Incremental Generation</h2></div></div></div><div class="section" title="The Incremental Generation Facade"><div class="titlepage"><div><div><h3 class="title"><a name="incrementalGeneration_usage_facade"></a>The Incremental Generation Facade</h3></div></div></div><p> |
| The easiest way to benefit from incremental generation is to use the |
| <span class="emphasis"><em>IncrementalGenerationFacade</em></span> workflow component: |
| </p><pre class="programlisting"> |
| <workflow> |
| <component id="incremental" |
| class="org.eclipse.xpand2.incremental.IncrementalGenerationFacade"> |
| <newModelFile value="path/to/your/model.file" /> |
| <oldModelFile value="path/to/backup/model.file" /> |
| <traceModelFile value="path/to/store/trace/model.trace" /> |
| <outlet path="path/to/your/outlet/" overwrite="true"/> |
| </component> |
| |
| <component id="generator" class="org.eclipse.xpand2.Generator"> |
| <expand value="your::template::Root FOR model" /> |
| <outlet path="temp/" overwrite="true"/> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel" /> |
| <vetoableCallback idRef="incremental" /> |
| </component> |
| </workflow> |
| </pre><p> |
| The <span class="emphasis"><em>IncrementalGenerationFacade</em></span> takes four |
| parameters: |
| |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> |
| The <span class="emphasis"><em>newModelFile</em></span> is the file |
| path where the model to generate is stored. This file is stored |
| in a model slot named <span class="emphasis"><em>model</em></span> |
| </p></li><li class="listitem"><p> |
| The <span class="emphasis"><em>oldModelFile</em></span> is the file |
| path where a copy of the previous state of the model is stored. |
| The model is automatically copied to this location after the |
| generation process and kept between generator invocations. |
| </p></li><li class="listitem"><p> |
| The <span class="emphasis"><em>traceModelFile</em></span> is the file |
| path where the <span class="emphasis"><em>trace model</em></span> of the generation |
| process is stored between generator invocations. |
| </p></li><li class="listitem"><p> |
| A regular <span class="emphasis"><em>outlet</em></span> list that must match the |
| one given for the regular generator invocation. |
| </p></li></ul></div><p> |
| |
| The <span class="emphasis"><em>IncrementalGenerationFacade</em></span> component must then |
| be passed as a <span class="emphasis"><em>vetoableCallback</em></span> parameter to the |
| invocation of the Xpand <span class="emphasis"><em>Generator</em></span>. |
| </p><p> |
| With the simple workflow given above, you should be able to observe |
| that for any given change in the model, only the files affected by |
| that change are regenerated, while all others remain untouched. Even |
| deleting elements will result in specific (previously generated) files |
| being deleted from the hard disk. |
| </p><p> |
| Note that you have to use file paths for all models because they |
| are physically copied on the hard disk. Passing locations that |
| can only be resolved from the classpath is not possible. |
| </p></div><div class="section" title="The Incremental Generation Callback"><div class="titlepage"><div><div><h3 class="title"><a name="incrementalGeneration_usage_callback"></a>The Incremental Generation Callback</h3></div></div></div><p> |
| While the <span class="emphasis"><em>IncrementalGenerationFacade</em></span> is easy |
| to use, it is rather restricted in its capabilities and fixed in the |
| operations it performs. Using the |
| <span class="emphasis"><em>IncrementalGenerationCallback</em></span> gives you more |
| control over the steps involved. A typical workflow for incremental |
| generation needs to perform the following tasks: |
| |
| </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> |
| Read the (current) model into a slot. |
| </p></li><li class="listitem"><p> |
| Read the previous state of the model into another slot. This |
| may, of course, not exist, e.g. for the very first invocation. |
| Full generation must be performed in this case. |
| </p></li><li class="listitem"><p> |
| Compute the changes between the two versions of the model |
| (if possible) and |
| put that <span class="emphasis"><em>diff model</em></span> into a slot. |
| </p></li><li class="listitem"><p> |
| Read the <span class="emphasis"><em>trace model</em></span> computed during the |
| previous generator invocation and put it into a slot. |
| As with the old state of the model, this may not exist, which |
| also leads to full generation. |
| </p></li><li class="listitem"><p> |
| Initialize the <span class="emphasis"><em>IncrementalGenerationCallback</em></span> |
| with the <span class="emphasis"><em>diff model</em></span> and the |
| <span class="emphasis"><em>trace model</em></span>. |
| </p></li><li class="listitem"><p> |
| Run the Xpand <span class="emphasis"><em>Generator</em></span> component with |
| the <span class="emphasis"><em>IncrementalGenerationCallback</em></span>. |
| </p></li><li class="listitem"><p> |
| Clean obsolete files, i.e. files that need to be deleted because |
| the corresponding elements in the model have been deleted. |
| </p></li><li class="listitem"><p> |
| Write the new <span class="emphasis"><em>trace model</em></span> computed during |
| code generation to the hard disk so that it is available |
| for the next generation process. |
| </p></li><li class="listitem"><p> |
| Make a backup copy of the model so that it can be compared with |
| the next version upon subsequent generator invocation. |
| </p></li></ol></div><p> |
| </p><p> |
| This is a sample workflow that performs all these steps: |
| </p><pre class="programlisting"> |
| <workflow> |
| <!-- read new model --> |
| <component id="modelreader" class="org.eclipse.emf.mwe.utils.Reader" |
| uri="model/my.model" |
| firstElementOnly="true" |
| modelSlot="model" |
| /> |
| <!-- read old model, copied from previous run. may not exist, so ignore missing model --> |
| <component id="oldmodelreader" class="org.eclipse.emf.mwe.utils.Reader" |
| uri="temp/old.model" |
| firstElementOnly="true" |
| ignoreMissingModel="true" |
| modelSlot="oldmodel" |
| /> |
| |
| <!-- compute diff. --> |
| <component id="compare" class="org.eclipse.xpand2.incremental.compare.EmfCompare" |
| oldModelSlot="oldmodel" |
| newModelSlot="model" |
| diffModelSlot="diff" |
| /> |
| |
| <!-- read trace model, produced by previous run. may not exist, so ignore missing model --> |
| <component id="tracemodelreader" class="org.eclipse.emf.mwe.utils.Reader" |
| uri="temp/trace.trace" |
| firstElementOnly="true" |
| ignoreMissingModel="true" |
| modelSlot="oldtrace" |
| /> |
| |
| <!-- this is the actual incremental generation callback --> |
| <component id="incremental" |
| class="org.eclipse.xpand2.incremental.IncrementalGenerationCallback" |
| diffModelSlot="diff" |
| oldTraceModelSlot="oldtrace" |
| newTraceModelSlot="trace" |
| /> |
| |
| <!-- generate code --> |
| <component id="generator" class="org.eclipse.xpand2.Generator"> |
| <expand value="resources::templates::Test::Test FOR model" /> |
| <outlet path="somewhere/" overwrite="true"/> |
| <metaModel class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel" /> |
| <vetoableCallback idRef="incremental" /> |
| </component> |
| |
| <!-- clean obsolete files --> |
| <component id="cleaner" class="org.eclipse.xpand2.incremental.FileCleaner"> |
| <oldTraceModelSlot value="oldtrace" /> |
| <newTraceModelSlot value="trace" /> |
| <outlet path="somewhere/" overwrite="true"/> |
| </component> |
| |
| <!-- write trace model --> |
| <component id="tracemodelwriter" class="org.eclipse.emf.mwe.utils.Writer" |
| modelSlot="trace" |
| uri="temp/trace.trace" |
| /> |
| |
| <!-- make backup copy of model --> |
| <component id="copier" class="org.eclipse.emf.mwe.utils.FileCopy" |
| sourceFile="model/my.model" |
| targetFile="temp/old.model" |
| /> |
| </workflow> |
| </pre></div></div><div class="section" title="Additional Notes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="incrementalGeneration_notes"></a>Additional Notes</h2></div></div></div><div class="section" title="Limitations"><div class="titlepage"><div><div><h3 class="title"><a name="incrementalGeneration_limitations"></a>Limitations</h3></div></div></div><p> |
| The incremental generation process can only be used with EMF-based models. |
| That's because all intermediate artifacts |
| (<span class="emphasis"><em>diff model</em></span> and <span class="emphasis"><em>trace model</em></span>) |
| which reference the original models are also stored as EMF models. It is |
| therefore not possible to refer to other model formats. Moreover, you |
| should make sure that your model has stable IDs for the individual |
| model elements so that the model comparison doesn't run into any |
| ambiguities. |
| </p><p> |
| Also note that at the moment, Xpand cannot track access to model elements |
| from JAVA extensions. This can lead to cases where a change in a specific |
| model element should trigger a specific (set of) |
| file(s) to be regenerated, but it actually doesn't. |
| That's because Xpand didn't know about the |
| model element being accessed during the original file generation, |
| so it has no indication that a regeneration is required. For that reason |
| you should try to access your model as much as possible from Xpand or |
| Xtend, and only resort to JAVA code when it is unavoidable. |
| </p></div><div class="section" title="Performance Considerations"><div class="titlepage"><div><div><h3 class="title"><a name="incrementalGeneration_performance"></a>Performance Considerations</h3></div></div></div><p> |
| The main performance benefits of incremental generation come from |
| <span class="emphasis"><em>not</em></span> doing things that are not necessary. Given |
| the workflow from <a class="xref" href="#incrementalGeneration_usage_callback" title="The Incremental Generation Callback">the section called “The Incremental Generation Callback”</a>, |
| it may seem counterproductive to first |
| perform a costly model comparison operation before it can even be |
| determined whether a file has to be generated or not. |
| </p><p> |
| While it is true that model comparison is a very expensive operation, |
| it turns out that it still outweighs the costs of unnecessarily |
| generating files, even if no postprocessing or subsequent compiler |
| invocation is involved. |
| </p><p> |
| That said, it is definitely preferrable to do without a model comparison |
| and rather capture the changes to the model on-the-fly. So whenever |
| you are working in a controlled environment, you may want to consider a |
| customized integration of the generator invocation with the |
| model editors. |
| </p></div></div></div><div class="chapter" title="Chapter 7. Improve performance using the backend"><div class="titlepage"><div><div><h2 class="title"><a name="backend"></a>Chapter 7. Improve performance using the backend</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#backend_background">Technical background</a></span></dt><dd><dl><dt><span class="section"><a href="#backend_interpretation_background">How it works in interpreted mode</a></span></dt></dl></dd><dt><span class="section"><a href="#backend_usage">Using the backend</a></span></dt><dd><dl><dt><span class="section"><a href="#backend_quickstart">A quickstart</a></span></dt><dt><span class="section"><a href="#backend_compiler">Compiling sources to Java</a></span></dt><dt><span class="section"><a href="#backend_execution">Executing workflows using the backend</a></span></dt><dt><span class="section"><a href="#java_middleend">Implementing functions in Java - the Java Annotations |
| Middleend</a></span></dt></dl></dd><dt><span class="section"><a href="#call_functions_backend">Call functions registered at the backend from Java</a></span></dt></dl></div><p> |
| Another approach to improve generation and model transformation |
| performance, is to use the M2T Backend. The M2T Backend is a new |
| execution engine for model to text (M2T) and model to model (M2M) |
| transformations that provides: |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> |
| compilation of M2T and M2M languages |
| supported on the backend by providing a middleend that translates the respective |
| language into a Backend abstract syntax tree. This AST is in turn compiled to Java. The |
| compiler is still experimental. |
| </li><li class="listitem"> |
| Backeend interpreted execution of M2T and M2M languages |
| supported on the backend. |
| </li><li class="listitem"> |
| performance improvement employing lazy string concatenation |
| and aggressive caching |
| </li><li class="listitem"> |
| language interoperability, e.g. mix Xpand with Xtend2 |
| </li></ul></div><p> |
| </p><p> |
| The M2T Backend provides a compiler that compiles resources written in Xpand / Xtend / Check and other |
| languages supported on the backend to Java. The backend is used as a common platform just |
| like the JVM is a common platform for multiple languages. Languages supported on the backend are interoperable |
| in same way as languages supported on the JVM are interoperable. |
| This enables you to import templates, extensions and transformations written |
| in other languages than Xpand/Xtend/Check and call functions declared |
| therein, e.g. call an QVT transformation from Xpand. As soon as a middleend for Xtend2 is available, |
| interoperability with old fashioned Xpand/Xtend/Check will be supported. |
| </p><p> |
| Beginning with the Eclipse Helios release (Eclipse 3.6) the M2T |
| Backend is part of M2T Xpand. As of the Eclipse Indigo release |
| the Backend Compiler has been added. |
| </p><div class="section" title="Technical background"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="backend_background"></a>Technical background</h2></div></div></div><p> |
| The basic idea behind the <span class="emphasis"><em>M2T Backend</em></span> |
| is to not build a compiler for every language but use an intermediary |
| "language", i.e. the backend abstract syntax tree, that is compiled |
| into executable Java code. Xpand, Xtend and Check are translated into a |
| backend AST by so called <span class="emphasis"><em>middleends</em></span>. |
| Middleends are specific for each language. Hence, there exists a |
| <span class="emphasis"><em>language specific middleend</em></span> |
| for each supported language. If a middleend |
| for a certain language is available, it is compilable into Java code and finally to bytecode |
| using a plain Java Compiler or automatically during the build Eclipse JDT Compiler. |
| In contrast to the backend language, Xpand, Xtend and Check are called <span class="emphasis"><em>frontend languages</em></span>. |
| </p><p> |
| The M2T Backend supports functional and aspect oriented |
| programming. Amongst others it supports language features such as: |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> |
| closures |
| </li><li class="listitem"> |
| higher order functions - use any expression as parameters, |
| even function calls |
| </li><li class="listitem"> |
| currying of functions |
| </li><li class="listitem"> |
| multi dispatch - call a function based on the runtime |
| parameter types as in Xpand / Xtend / Check instead of the |
| statically assigned parameter types as in Java |
| </li><li class="listitem"> |
| guards on functions - constrain the execution of a |
| function to certain conditions defined in the guard |
| </li><li class="listitem"> |
| deferred evaluation of expressions - use the function call |
| as a placeholder and evaluate the expression later |
| </li><li class="listitem"> |
| AOP |
| </li><li class="listitem"> |
| declare functions in Java using several annotations |
| </li><li class="listitem"> |
| Support for multiple typesystems a.k.a metamodels. |
| Currently JavaBeans, EMF, Eclipse UML2 and XSD are supported. |
| </li></ul></div><p> |
| </p><div class="section" title="How it works in interpreted mode"><div class="titlepage"><div><div><h3 class="title"><a name="backend_interpretation_background"></a>How it works in interpreted mode</h3></div></div></div><p> |
| In interpreted mode the following steps |
| are executed: |
| |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> |
| Read a resource, e.g. an Xpand template. |
| </li><li class="listitem"> |
| Find the responsible <span class="emphasis"><em>middleend</em></span>, |
| that is capable to convert the <span class="emphasis"><em>frontend language</em></span> |
| AST (e.g. Xpand) into the <span class="emphasis"><em>backend AST</em></span>. Whether |
| a middleend can handle the transformation of a certain |
| frontend language AST into the backend AST, is determined based on the |
| file ending of the resource, e.g ".xpt" and by trying to parse the resource |
| with the middleends frontend parser. |
| </li><li class="listitem"> |
| Finally, execute the backend AST using the backend. |
| </li></ul></div><p> |
| </p></div></div><div class="section" title="Using the backend"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="backend_usage"></a>Using the backend</h2></div></div></div><div class="section" title="A quickstart"><div class="titlepage"><div><div><h3 class="title"><a name="backend_quickstart"></a>A quickstart</h3></div></div></div><p> |
| Before you can start, you need to install the following features: |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> |
| Xtend Backend |
| </li><li class="listitem"> |
| Xtend Backend UML2Types |
| </li><li class="listitem"> |
| Xtend Backend XSDTypes |
| </li><li class="listitem"> |
| Xtend Backend Compiler |
| </li><li class="listitem"> |
| Xtend Backend UI (only required by the compiler) |
| </li><li class="listitem"> |
| Xpand Middleend |
| </li><li class="listitem"> |
| Xpand Middleend UI (only required by the compiler) |
| </li><li class="listitem"> |
| Xtend Middleend |
| </li><li class="listitem"> |
| Xtend Middleend UI (only required by the compiler) |
| </li></ul></div><p> |
| Altenatively you may install the<span class="emphasis"><em>Xtend Backend SDK</em></span> |
| and <span class="emphasis"><em>Xpand Middleend SDK</em></span> |
| </p><p> |
| As a quickstart you may use the <span class="emphasis"><em>Xpand Project</em></span> |
| wizard and select "Generate a sample EMF based Xpand project". After |
| completion of the wizard you will find the workflow file |
| "generatorWithBackend.mwe" in the "workflow"-folder. The workflow is |
| ready to use the backend for generation. |
| </p></div><div class="section" title="Compiling sources to Java"><div class="titlepage"><div><div><h3 class="title"><a name="backend_compiler"></a>Compiling sources to Java</h3></div></div></div><p> |
| The compiler can be activated as a builder by adding M2T Backend Compiler nature to the project. This is |
| done selecting "Configure" > "Add M2T Backend Compiler" from the context menu of the Xpand project. All |
| Xpand/Xtend/Check resources will then be compiler to Java source files into the "backend-gen" folder of the |
| project. When selecting "Clean..." from the project menu the Backend Compiler will do a full build, |
| while changing a Xpand/Xtend/Check resource will compile this resource incrementally. |
| </p><p> |
| The compiler is still experimental. |
| </p></div><div class="section" title="Executing workflows using the backend"><div class="titlepage"><div><div><h3 class="title"><a name="backend_execution"></a>Executing workflows using the backend</h3></div></div></div><p> |
| The backend can execute functions and templates that have been compiled to Java or other resources that |
| can be handled by one of the available middleends. It automatically recognizes compiled resources |
| if available on the build path and prefers them over native Xpand/Xtend/Check resources. |
| </p><p> |
| The best way to execute compiled functions/templates is to use the XpandComponent or XtendComponent. The |
| name of the function to be called is the same fully qualified name as defined in Xpand/Xtend/Check. |
| </p><div class="section" title="Setting up the backend languages"><div class="titlepage"><div><div><h4 class="title"><a name="backend_setup"></a>Setting up the backend languages</h4></div></div></div><p> |
| Before you can use a language like Xpand with the backend, the |
| responsible middleend must be registered at the backend. This is done |
| with the <code class="classname">org.eclipse.xtend.middleend.LanguageSetup</code>. |
| Middleends are being called a <code class="classname">languageContributor</code> |
| here. You can register any language specific middleend. Language |
| specific middleend implement the interface |
| <code class="classname">org.eclipse.xtend.middleend.plugins.LanguageSpecificMiddleEnd |
| </code>. To register the Xpand, Xtend and Check middleends, do the |
| following in the workflow before invoking the middleend component of |
| any of the respective languages: |
| </p><pre class="programlisting"><component |
| class="org.eclipse.xtend.middleend.LanguageSetup"> |
| <languageContributor |
| value="org.eclipse.xtend.middleend.xtend.plugin.OldXtendRegistryFactory"/> |
| <languageContributor |
| value="org.eclipse.xtend.middleend.xtend.plugin.OldCheckRegistryFactory"/> |
| <languageContributor |
| value="org.eclipse.xtend.middleend.xpand.plugin.OldXpandRegistryFactory"/> |
| </component></pre><p> |
| Now that the middleends are registered, you can use the respective middleend |
| workflow components to use the backend in interpreted mode. |
| </p></div><div class="section" title="Calling Xpand templates - the generator"><div class="titlepage"><div><div><h4 class="title"><a name="xpand_middleend_usage"></a>Calling Xpand templates - the generator</h4></div></div></div><p> |
| The Xpand middleend introduces a new component to be used instead of |
| <code class="classname">org.eclipse.xpand2.Generator</code> |
| to call Xpand templates from a workflow. The component has the same |
| parameters as the Xpand <code class="classname">Generator</code> |
| component. Hence, the following workflow fragment calls the template |
| <code class="classname">template::Template::main</code>: |
| </p><pre class="programlisting"><component class="org.eclipse.xtend.middleend.xpand.XpandComponent"> |
| <metaModel idRef="mm_emf"/> |
| <expand value="template::Template::main FOR model" /> |
| <outlet path="${src-gen}" > |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier" /> |
| </outlet> |
| </component></pre><p> |
| The component supports all properties of <code class="classname">Generator</code>, |
| except <code class="classname">collectProfileSummary</code> and |
| <code class="classname">verboseProfileFilename</code> |
| </p></div><div class="section" title="Executing Check on the backend"><div class="titlepage"><div><div><h4 class="title"><a name="check_middleend_usage"></a>Executing Check on the backend</h4></div></div></div><p> |
| Just as the Xpand middleend, the Check middleend also provides a new component |
| to execute checks on the backend. The component |
| <code class="classname">org.eclipse.xtend.check.CheckComponent</code> |
| has to be replaced with <code class="classname">org.eclipse.xtend.middleend.xtend.CheckComponent |
| </code>. The new component uses the same properties as |
| <code class="classname">org.eclipse.xtend.check.CheckComponent</code>. |
| Hence calling checks using the backend would look like this: |
| </p><pre class="programlisting"><component class="org.eclipse.xtend.middleend.xtend.CheckComponent"> |
| <metaModel idRef="mm_emf"/> |
| <checkFile value="metamodel::Checks" /> |
| <emfAllChildrenSlot value="model"/> |
| </component> </pre></div><div class="section" title="Executing Xtend extensions on the backend"><div class="titlepage"><div><div><h4 class="title"><a name="xtend_middleend_usage"></a>Executing Xtend extensions on the backend</h4></div></div></div><p> |
| To invoke Xtend extensions from the workflow, the Xtend middleend |
| introduces the new component |
| <code class="classname">org.eclipse.xtend.middleend.xtend.XtendComponent |
| </code>. The new component provides the same configuration |
| properties as the old one. Hence, you may invoke the extension |
| <code class="classname">extensions::modification::modify</code> |
| using the following workflow fragment: |
| </p><pre class="programlisting">>component class="org.eclipse.xtend.middleend.xtend.XtendComponent"> |
| <metaModel idRef="mm_emf"/> |
| <invoke value="extensions::modification::modify(model)"/> |
| </component> </pre></div></div><div class="section" title="Implementing functions in Java - the Java Annotations Middleend"><div class="titlepage"><div><div><h3 class="title"><a name="java_middleend"></a>Implementing functions in Java - the Java Annotations |
| Middleend</h3></div></div></div><p> |
| Functions may also be contributed by the Java Annotations Middleend |
| to the M2T Backend. The middleend is implemented by |
| <code class="classname">org.eclipse.xtend.middleend.javaannotations.JavaFunctionClassContributor |
| </code>. Registration of Java classes is done by calling the method |
| <code class="classname">classAsResource</code> with a class. |
| </p><p> |
| Functions have qualified names in the backend represented by |
| <code class="classname">org.eclipse.xtend.backend.common.QualifiedName</code> |
| consisting of a namespace and a simple name. E.g. the Xpand |
| definition <code class="classname">template::Template::main</code> |
| has the namespace <code class="classname">template::Template</code> |
| and the simple name <code class="classname">main</code>. The String representation |
| of the QualifiedName would be <code class="classname">template::Template::main</code>. |
| When registering Java Defined Functions, normally only the simple |
| name of a function will be defined as it's name. The simple name is method name. |
| To set the qualified name of a function use the annotation |
| <code class="classname">@M2tQualifiedName</code>. The namespace will be |
| derived from the fully qualified class name. |
| </p><p> |
| Per default, all public methods will be registered as functions. To |
| prevent the registration of a method, annotate it with |
| <code class="classname">@M2tNoFunction</code>. |
| You may also use one of the following annotations: |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><code class="classname">@M2tCached</code> - use caching |
| </li><li class="listitem"><code class="classname">@M2tPrivateFunction</code> - mark the function as private |
| </li><li class="listitem"><code class="classname">@M2tAroundAdvice(pointcut)</code> - use the method as around advice. The pointcut has the |
| parameters: |
| <div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><code class="classname">namePattern</code> - a pattern for function names as in Xpand |
| <code class="classname">paramTypeNames</code> - an array with patterns of parameter type names |
| <code class="classname">hasVarArgs</code> - true, if the matching functions have any number of |
| parameters after <code class="classname">paramTypeNames</code> the specified in the pointcut |
| </li></ul></div></li></ul></div><p> |
| </p><p> |
| Functions defined by methods of a Java class can be directly called |
| on the facade |
| <code class="classname">org.eclipse.xtend.middleend.javaannotations.JavaAnnotationBackendFacade |
| </code>. Call the method invoke to invoke functions defined in Java: |
| </p><pre class="programlisting">invokeFunction(String className, BackendTypesystem |
| ts, QualifiedName functionName, List<?> params) |
| </pre><p> |
| </p></div></div><div class="section" title="Call functions registered at the backend from Java"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="call_functions_backend"></a>Call functions registered at the backend from Java</h2></div></div></div><p> |
| To call functions registered at the backend use the |
| <code class="classname">org.eclipse.xtend.backend.BackendFacade</code>. |
| To invoke a function on the backend call the method |
| </p><pre class="programlisting">invoke (ExecutionContext ctx, QualifiedName |
| functionName, List<? extends Object> params) |
| </pre><p> |
| </p></div></div><div class="chapter" title="Chapter 8. UML2 Adapter"><div class="titlepage"><div><div><h2 class="title"><a name="uml_adapter"></a>Chapter 8. UML2 Adapter</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#uml_adapter_introduction">Introduction</a></span></dt><dt><span class="section"><a href="#uml_adapter_installation">Installation</a></span></dt><dt><span class="section"><a href="#uml_adapter_eclipse_setup">Setting up Eclipse</a></span></dt><dd><dl><dt><span class="section"><a href="#uml_adapter_setup_profiles">Profiles in Eclipse</a></span></dt></dl></dd><dt><span class="section"><a href="#uml_adapter_runtime_configuration">Runtime Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#uml_adapter_runtime_workflow">Workflow</a></span></dt></dl></dd></dl></div><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml_adapter_introduction"></a>Introduction</h2></div></div></div><p> It is based upon the UML2 |
| 2.0 framework of Eclipse and provides a type mapping from the UML 2.1 |
| metamodel implementation to the Xpand type system. Hence one can access |
| the whole UML2 metamodel from <span class="emphasis"><em>Check</em></span>, |
| <span class="emphasis"><em>Xtend</em></span>, and <span class="emphasis"><em>Xpand</em></span>. Additionally, |
| and more important, the adapter dynamically maps stereotypes applied to |
| model elements to Xpand types and tagged values to Xpand properties. You |
| do not have to implement additional Java classes anymore. Just export your |
| models and applied profiles. That's all!</p></div><div class="section" title="Installation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml_adapter_installation"></a>Installation</h2></div></div></div><p>First you need to install the UML2 feature from eclipse.org:</p><p><a class="ulink" href="http://download.eclipse.org/modeling/mdt/updates/releases/" target="_new">http://download.eclipse.org/modeling/mdt/updates/releases/</a></p><p>The Xpand uml2adapter is available from the Xpand update |
| site:</p><p><a class="ulink" href="http://download.eclipse.org/modeling/m2t/updates/releases/" target="_new">http://download.eclipse.org/modeling/m2t/updates/releases/</a></p><p>(Go to the home page of the project and find the current location if |
| either of the sites do not work)</p><p>Restart your Eclipse workbench when Eclipse asks you to do |
| so.</p></div><div class="section" title="Setting up Eclipse"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml_adapter_eclipse_setup"></a>Setting up Eclipse</h2></div></div></div><p>You need to configure your project (or the whole workspace) to use |
| the UML2Adapter.</p><p>Right-click on the project and choose |
| '<span class="emphasis"><em>properties</em></span>' from the pop-up menu. Therein open the |
| '<span class="emphasis"><em>Xtend/Xpand</em></span>' tab, activate the checkboxes |
| <span class="emphasis"><em>Enable project specific settings</em></span> and add the |
| <span class="emphasis"><em>UML2 profiles</em></span> metamodel contributor. Use the |
| <span class="emphasis"><em>Up</em></span>-button to push the UML2 profiles contributor to |
| the first position.</p><div class="section" title="Profiles in Eclipse"><div class="titlepage"><div><div><h3 class="title"><a name="uml_adapter_setup_profiles"></a>Profiles in Eclipse</h3></div></div></div><p>If you want Eclipse to register your specific profile in order to |
| provide static type checking and code completion in the editors, the |
| profiles (*.profile.uml or *.profile.uml2) need to be on the classpath |
| of the project (e.g. are contained in a <code class="filename">src</code> |
| folder)</p></div></div><div class="section" title="Runtime Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml_adapter_runtime_configuration"></a>Runtime Configuration</h2></div></div></div><p>At runtime, you just need the |
| <code class="filename">org.eclipse.xtend.typesystem.uml2-1.0.0.jar</code> (or |
| later). You can use the dependency mechanism of Eclipse from the PDE, or |
| copy or reference the respective JAR file directly. It does not matter, |
| you just have to take care that it is on the classpath.</p><div class="section" title="Workflow"><div class="titlepage"><div><div><h3 class="title"><a name="uml_adapter_runtime_workflow"></a>Workflow</h3></div></div></div><p>If you have written some <span class="emphasis"><em>Check</em></span>, |
| <span class="emphasis"><em>Xtend</em></span> or <span class="emphasis"><em>Xpand</em></span> files and now |
| want to execute them, you have to provide the right |
| configuration.</p><p>You need to configure the UML2 metamodel and a profile metamodel |
| <span class="emphasis"><em>for each profile</em></span> you used directly. A typical |
| configuration looks like this:</p><pre class="programlisting"><workflow> |
| <bean class="org.eclipse.xtend.typesystem.uml2.Setup" standardUML2Setup="true" /> |
| <component class="org.eclipse.xtend.typesystem.emf.XmiReader"> |
| ... |
| </component> |
| <component class="org.eclipse.xpand2.Generator"> |
| <metaModel class="org.eclipse.xtend.typesystem.uml2.UML2MetaModel"/> |
| <metaModel class="org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel"> |
| <profile value="myProfile.profile.uml2"/> |
| </metaModel> |
| ... |
| </component> |
| <workflow></pre><p><span class="emphasis"><em>Note the bean configuration in the second line. It |
| statically configures the XmiReader to use the right factories for *.uml |
| and *.uml2 files. This is very important.</em></span></p><p>If you are invoking several Xpand components, you should use the |
| <code class="varname">id</code> / <code class="varname">idRef</code> mechanism:</p><pre class="programlisting"><workflow> |
| <bean class="org.eclipse.xtend.typesystem.uml2.Setup" standardUML2Setup="true" /> |
| <component class="org.eclipse.xtend.typesystem.emf.XmiReader"> |
| ... |
| </component> |
| <component class="org.eclipse.xpand2.Generator"> |
| <metaModel id="uml" |
| class="org.eclipse.xtend.typesystem.uml2.UML2MetaModel"/> |
| <metaModel id="profile" |
| class="org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel"> |
| <profile value="myProfile.profile.uml2"/> |
| </metaModel> |
| ... |
| </component></pre></div></div></div><div class="chapter" title="Chapter 9. XSD Adapter"><div class="titlepage"><div><div><h2 class="title"><a name="xsd_reference"></a>Chapter 9. XSD Adapter</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#xsd_reference_prerequisites">Prerequisites</a></span></dt><dt><span class="section"><a href="#xsd_reference_overview">Overview</a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components">Workflow Components</a></span></dt><dd><dl><dt><span class="section"><a href="#xsd_reference_workflow_components_xsdmetamodel"> |
| <code class="classname">XSDMetaModel</code> |
| </a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components_xmlreader"> |
| <code class="classname">XMLReader</code> |
| </a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components_xmlwriter"> |
| <code class="classname">XMLWriter</code> |
| </a></span></dt><dt><span class="section"><a href="#xsd_reference_workflow_components_xmlbeautifier"> |
| <code class="classname">XMLBeautifier</code> |
| </a></span></dt></dl></dd><dt><span class="section"><a href="#xsd_reference_xsd2ecore">Behind the scenes: Transforming XSD to Ecore</a></span></dt><dt><span class="section"><a href="#xsd_reference_declare_xsd">How to declare XML Schemas</a></span></dt></dl></div><p>The XSD Adapter allows Xpand to read/write XML files as models and to |
| use XML Schemas (XSDs) as meta models. This reference provides in-depth |
| details, for a quick and pragmatic introduction see <a class="xref" href="#xsd_tutorial" title="Chapter 11. XSD Tutorial">Chapter 11, <i>XSD Tutorial</i></a> .</p><div class="section" title="Prerequisites"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_reference_prerequisites"></a>Prerequisites</h2></div></div></div><p> |
| Please take a look at <a class="xref" href="#xsd_tutorial_setup" title="Setup">the section called “Setup”</a>. |
| </p></div><div class="section" title="Overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_reference_overview"></a>Overview</h2></div></div></div><p>The XSD Adapter performs two major tasks:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>It converts XML Schemas (XSDs) to Ecore models in a transparent |
| manner, so that the Ecore models are hidden from the user. This is |
| done in the workflow as well as in the IDE (to allow XSD-aware code |
| completion for Xtend/Xpand/Check). For details about the mapping see |
| <a class="xref" href="#xsd_reference_xsd2ecore" title="Behind the scenes: Transforming XSD to Ecore">the section called “Behind the scenes: Transforming XSD to Ecore”</a> . For details about the |
| workflow integration see <a class="xref" href="#xsd_reference_workflow_components" title="Workflow Components">the section called “Workflow Components”</a></p></li><li class="listitem"><p>It extends the EmfMetaModel with concepts that are needed for |
| XSDs. Theses are, for example, support for feature maps (needed to |
| handle comments, nested text, CDATA and processing instructions), |
| QNames, EMaps and composed Simpletypes.</p></li></ol></div></div><div class="section" title="Workflow Components"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_reference_workflow_components"></a>Workflow Components</h2></div></div></div><p> |
| The XSD Adapter provides the following workflow components: |
| </p><div class="section" title="XSDMetaModel"><div class="titlepage"><div><div><h3 class="title"><a name="xsd_reference_workflow_components_xsdmetamodel"></a> |
| <code class="classname">XSDMetaModel</code> |
| </h3></div></div></div><p>The XSDMetaModel loads the specified XSD, transforms them to Ecore |
| models and makes them available for the other MWE components. If XSDs |
| include/import other XSDs or if XML files reference XSDs via |
| <span class="property">schemaLocation</span>, theses XSDs are also loaded |
| (details: <a class="xref" href="#xsd_reference_declare_xsd" title="How to declare XML Schemas">the section called “How to declare XML Schemas”</a> ). The most |
| common scenario is to declare the <code class="classname">XSDMetaModel</code> |
| within an <code class="classname">XMLReader</code>:</p><pre class="programlisting"><component class="org.eclipse.xtend.typesystem.xsd.XMLReader"> |
| <modelSlot value="model" /> |
| <uri value="model.xml" /> |
| <metaModel id="mm" class="org.eclipse.xtend.typesystem.xsd.XSDMetaModel"> |
| <schemaFile value="metamodel.xsd" /> |
| <registerPackagesGlobally value="true" /> |
| </metaModel> |
| </component></pre><p>Another option is to specify an |
| <code class="classname">XSDMetaModel</code> independently of other components as |
| a bean:</p><pre class="programlisting"><bean id="<span class="bold"><strong>mymetamodel</strong></span>" class="org.eclipse.xtend.typesystem.xsd.XSDMetaModel"> |
| <schemaFile value="metamodel.xsd" /> |
| </bean> |
| <component class="org.eclipse.xtend.typesystem.xsd.XMLReader"> |
| <modelSlot value="model" /> |
| <uri value="model.xml" /> |
| <metaModel <span class="bold"><strong>idRef="mymetamodel"</strong></span> /> |
| </component></pre><p>Attention: It can lead to errors when XSDs are loaded multiple |
| times, which can only happen when using multiple |
| <code class="classname">XSDMetaModels</code> within one workflow. The safe way |
| to go is to declare just one <code class="classname">XSDMetaModel</code> per |
| workflow and reference it from all components that need it.</p><p>Properties:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="property">schemaFile</span>: optional, allowed multiple |
| times: Specifies an XSD file which is being loaded. The path can be |
| a complete URI, or relative to the project root or classpath.</p></li><li class="listitem"><p><span class="property">registerPackagesGlobally</span>: optional, |
| default "<span class="property">false</span>": If <span class="property">true</span>, |
| generated EPackages are registered to |
| <code class="classname">org.eclipse.emf.ecore.EPackage.Registry.INSTANCE</code>, |
| EMF's global package registry. Warning: when running workflows from |
| your own java code, make sure to remove the generated packages from |
| the registry before the next run!</p></li></ul></div></div><div class="section" title="XMLReader"><div class="titlepage"><div><div><h3 class="title"><a name="xsd_reference_workflow_components_xmlreader"></a> |
| <code class="classname">XMLReader</code> |
| </h3></div></div></div><p>The <code class="classname">XMLReader</code> reads one XML file which is |
| valid according to the XSDs loaded by the |
| <code class="classname">XSDMetaModel</code>. The XML file is loaded as a model |
| and stored in the specified slot. Example:</p><pre class="programlisting"><component class="org.eclipse.xtend.typesystem.xsd.XMLReader"> |
| <modelSlot value="model" /> |
| <uri value="model.xml" /> |
| <metaModel idRef="mymetamodel" /> |
| </component></pre><p>Properties:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="property">slot</span>: required: The name of the slot |
| which in which the loaded model is stored. Other workflow components |
| can access the model via referring to this slot.</p></li><li class="listitem"><p><span class="property">uri</span>: required: The file name of the XML |
| file which should be read. Absolute URIs, and pathnames relative to |
| the project root or to the classpath are valid.</p></li><li class="listitem"><p><span class="property">metaModel</span>: optional: Specifies the |
| <code class="classname">XSDMetaModel</code> (see <a class="xref" href="#xsd_reference_workflow_components_xsdmetamodel" title="XSDMetaModel">the section called “ |
| <code class="classname">XSDMetaModel</code> |
| ”</a>) for the |
| <code class="classname">XMLReader</code>. In case no |
| <code class="classname">XSDMetaModel</code> is specified, an |
| <code class="classname">XSDMetaModel</code> with default configuration is |
| instantiated implicitly. It is important to pay attention that all |
| needed XSDs can be found while the loading process: <a class="xref" href="#xsd_reference_declare_xsd" title="How to declare XML Schemas">the section called “How to declare XML Schemas”</a>.</p></li><li class="listitem"><p><span class="property">useDocumentRoot</span>: optional, default |
| "<span class="property">false</span>": Dealing with XML files as models, most |
| people think of the XML's root element as the model's root object. |
| This is the default used by the <code class="classname">XMLReader</code>. |
| But the XML's root element actually has a parent, the so-called |
| DocumentRoot. Additionally the DocumentRoot contains |
| comments/processing instructions and CDATA section which appears |
| before or after the XML's root element, and, most notably, the |
| DocumentRoot contains information about the used namespaces. If |
| <span class="property">useDocumentRoot</span> is set to |
| <span class="property">true</span>, the <code class="classname">XMLReader</code> |
| stores the DocumentRoot-Object instead the XML's root element's |
| object to the specified slot.</p></li><li class="listitem"><p><span class="property">option</span>: optional, can be specified |
| multiple times: Option specifies a key-value-pair, which is handed |
| on to the EMF's XMLResource in the loading process. Valid options |
| are documented via JavaDoc in interface <a class="ulink" href="http://help.eclipse.org/ganymede/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html" target="_new"> |
| <code class="classname">org.eclipse.emf.ecore.xmi.XMLResource</code> |
| </a>. Additionally, the <code class="classname">XMLReader</code> |
| supports these options:</p><div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><p><span class="property">DEFAULT_NAMESPACE</span>: Specifies a |
| default namespace, in case the XML file does not declare |
| one:</p><pre class="programlisting"><option key="DEFAULT_NAMESPACE" val="http://www.dlese.org/Metadata/opml" /></pre></li><li class="listitem"><p><span class="property">NAMESPACE_MAP</span>: Specifies a mapping |
| for namespaces, which is applied when loading XML files.</p><pre class="programlisting"><option key="NAMESPACE_MAP"> |
| <val class="org.eclipse.xtend.typesystem.xsd.lib.MapBean"> |
| <mapping from="http://www.eclipse.org/modeling/xpand/example/model/wrong" |
| to="http://www.eclipse.org/modeling/xpand/example/model/loadcurve" /> |
| </val> |
| </option></pre></li></ul></div></li></ul></div></div><div class="section" title="XMLWriter"><div class="titlepage"><div><div><h3 class="title"><a name="xsd_reference_workflow_components_xmlwriter"></a> |
| <code class="classname">XMLWriter</code> |
| </h3></div></div></div><p>The <code class="classname">XMLWriter</code> writes the model stored in a |
| slot to an XML file. If the slot contains a collection of models, each |
| one is written to a separate file. The model(s) must have been |
| instantiated using an XSD-based meta model. Example:</p><pre class="programlisting"><component class="org.eclipse.xtend.typesystem.xsd.XMLWriter"> |
| <metaModel idRef="svgmm" /> |
| <modelSlot value="svgmodel" /> |
| <uri value="src-gen/mycurve.svg" /> |
| </component></pre><p>Properties:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="property">slot</span>: required: The name of the slot |
| which holds the model or the collection of models which shall be |
| serialized to XML.</p></li><li class="listitem"><p><span class="property">metaModel</span>: required: The instance of |
| <code class="classname">XSDMetaModel</code>, which holds the XSD that the |
| supplied models are based on. Also see <a class="xref" href="#xsd_reference_workflow_components_xsdmetamodel" title="XSDMetaModel">the section called “ |
| <code class="classname">XSDMetaModel</code> |
| ”</a></p></li><li class="listitem"><p><span class="property">uri</span>: required if no |
| <span class="property">uriExpression</span> is specified: The file name of |
| the XML file which should be written. Absolute URIs are valid. Use |
| relative path names on your own risk.</p></li><li class="listitem"><p><span class="property">uriExpression</span>: required if no |
| <span class="property">uri</span> is specified: In the scenario where |
| multiple XML files are written, this provides a mechanism to |
| determine the file name for each of them. The Xtend-expression |
| specified in <code class="classname">expression</code> is evaluated for each |
| file and has to return a file name. The model that is going to be |
| written is accessible in the expression via a variable that has the |
| name specified in <code class="classname">varName</code>. Example: |
| </p><pre class="programlisting"><uriExpression varName="docroot" expression="'src-gen/'+ecore2xsd::getFileName(docroot)" /></pre></li><li class="listitem"><p><span class="property">option</span>: optional, can be specified |
| multiple times: Option specifies a key-value-pair, which is handed |
| on to the EMF's XMLResource in the writing process. Valid options |
| are documented via JavaDoc in interface <a class="ulink" href="http://help.eclipse.org/ganymede/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html" target="_new"> |
| <code class="classname">org.eclipse.emf.ecore.xmi.XMLResource</code> |
| </a>.</p></li></ul></div></div><div class="section" title="XMLBeautifier"><div class="titlepage"><div><div><h3 class="title"><a name="xsd_reference_workflow_components_xmlbeautifier"></a> |
| <code class="classname">XMLBeautifier</code> |
| </h3></div></div></div><p>The <code class="classname">XMLBeautifier</code> uses EMF to load the XML |
| file, formats the mixed content (elements and text contained by the same |
| element) and writes the file back to disk applying a nice indentation |
| for the elements. The <code class="classname">XMLBeautifier</code> is not |
| intended to be used in combination with the |
| <code class="classname">XMLWriter</code>, since the |
| <code class="classname">XMLWriter</code> cares about indentation by itself. |
| Instead, use it for "manually" constructed XML files using Xpand. Since |
| the frameworks for loading/storing XML always load the whole file into a |
| complex data structure in memory, this approach does not scale well for |
| huge XML files. Example:</p><pre class="programlisting"><component class="org.eclipse.xpand2.Generator"> |
| <metaModel idRef="mm" /> |
| <expand value="${src-pkg}::${file}::Root FOR '${out}'" /> |
| <outlet path="${src-gen-dir}" /> |
| <beautifier class="org.eclipse.xtend.typesystem.xsd.XMLBeautifier"> |
| <maxLineWidth value="60" /> |
| <formatComments value="true" /> |
| <fileExtensions value=".xml, .html" /> |
| </beautifier> |
| </component></pre><p>Properties:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="property">maxLineWidth</span>: optional: Specifies the |
| number of character after which a linewrap should be |
| performed.</p></li><li class="listitem"><p><span class="property">formatComments</span>: optional, default |
| <span class="property">true</span>: Specifies if formatting should also be |
| applied to comments.</p></li><li class="listitem"><p><span class="property">fileExtensions</span>: optional, default |
| "<span class="property">.xml, .xsl, .xsd, .wsdd, .wsdl</span>": Specifies a |
| filter for which files formatting should be applied. Only files that |
| match one of the specified file extensions are processed.</p></li><li class="listitem"><p><span class="property">loadOption</span>: optional, can be specified |
| multiple times: Option specifies a key-value-pair, which is handed |
| on to the EMF's XMLResource in the loading process. Valid options |
| are documented via JavaDoc in interface <a class="ulink" href="http://help.eclipse.org/ganymede/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html" target="_new"> |
| <code class="classname">org.eclipse.emf.ecore.xmi.XMLResource</code> |
| </a>.</p></li><li class="listitem"><p><span class="property">saveOption</span>: optional, can be specified |
| multiple times: Same as <span class="property">loadOption</span>, except for |
| the difference that these options are applied while the writing |
| process. Example: </p><pre class="programlisting"><saveOption key="XML_VERSION" val="1.1" /> |
| <saveOption key="ENCODING" val="ASCII" /></pre></li></ul></div></div></div><div class="section" title="Behind the scenes: Transforming XSD to Ecore"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_reference_xsd2ecore"></a>Behind the scenes: Transforming XSD to Ecore</h2></div></div></div><p>In the code generation process an XML Schema is transformed to an |
| EMF Ecore model, which is then used as a meta model by EMF. XSD complex |
| data types are mapped to EClasses, XSD simple data types are mapped to EMF |
| data types defined in <code class="classname"> |
| org.eclipse.emf.ecore.xml.type.XMLTypePackage </code> and <code class="classname"> |
| org.eclipse.xtend.typesystem.xsd.XSDMetaModel </code> maps them to Xpand |
| data types. The document <span class="emphasis"><em><a class="ulink" href="http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf" target="_new">XML |
| Schema to Ecore Mapping</a></em></span> explains the mapping's details. |
| <a class="ulink" href="http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf" target="_new">http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf</a></p></div><div class="section" title="How to declare XML Schemas"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_reference_declare_xsd"></a>How to declare XML Schemas</h2></div></div></div><p>There are three different ways to declare your XSDs. It does not |
| matter which way you choose, or how you combine them, as long as the XSD |
| Adapter can find all needed schemas.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Within the Workflow: <code class="classname"> |
| org.eclipse.xtend.typesystem.xsd.XSDMetaModel </code> can have any |
| amount of <code class="classname">schemaFile</code> elements.</p><pre class="programlisting"><component class="org.eclipse.xtend.typesystem.xsd.XMLReader"> |
| <modelSlot value="model" /> |
| <uri value="${file}" /> |
| <metaModel id="mm" class="org.eclipse.xtend.typesystem.xsd.XSDMetaModel"> |
| <schemaFile value="model/loadcurve.xsd" /> |
| <schemaFile value="model/device.xsd" /> |
| </metaModel> |
| </component></pre></li><li class="listitem"><p>Within the XML file: XML files can contain |
| <code class="classname">schemaLocation</code> attributes which associate the |
| schema's namespace with the schema's filename. If the schema is |
| created using WTP like described in <a class="xref" href="#xsd_tutorial_model" title="Step 3: Create a Model using XML">the section called “Step 3: Create a Model using XML”</a> , the |
| <code class="classname">schemaLocation</code> attribute is created |
| automatically.</p><pre class="programlisting"><?xml version="1.0" encoding="UTF-8"?> |
| <device:Device |
| xmlns:device="http://www.eclipse.org/modeling/xpand/example/model/device" |
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
| xsi:schemaLocation="http://www.eclipse.org/modeling/xpand/example/model/device device.xsd"> |
| <device:Name>MyLaptop</device:Name> |
| </device:Device></pre></li><li class="listitem"><p>Within an XSD: If one schema imports another, the |
| <code class="classname">import</code> element can have a |
| <code class="classname">schemaLocation</code> attribute, too.</p><pre class="programlisting"><?xml version="1.0" encoding="UTF-8"?> |
| <schema |
| targetNamespace="http://www.eclipse.org/modeling/xpand/example/model/device" |
| elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema" |
| xmlns:tns="http://www.eclipse.org/modeling/xpand/example/model/device" |
| xmlns:lc="http://www.eclipse.org/modeling/xpand/example/model/loadcurve" |
| xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"> |
| |
| <import |
| namespace="http://www.eclipse.org/modeling/xpand/example/model/loadcurve" |
| schemaLocation="loadcurve.xsd"> |
| </import> |
| |
| <complexType name="Device"> |
| <sequence> |
| <element name="Name" type="string" /> |
| <element name="LoadCurve" type="lc:LoadCurve" /> |
| </sequence> |
| </complexType> |
| |
| <element name="Device" type="tns:Device"></element> |
| </schema></pre></li></ol></div></div></div></div><div class="part" title="Part II. Tutorials"><div class="titlepage"><div><div><h1 class="title"><a name="Tutorials"></a>Part II. Tutorials</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#uml2example">10. UML2 Example</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_setup_eclipse">Setting up Eclipse</a></span></dt><dt><span class="section"><a href="#uml2example_setup_project">Setting up the project</a></span></dt><dt><span class="section"><a href="#uml2example_create_model">Creating a UML2 Model</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_modelling">Modelling the content</a></span></dt></dl></dd><dt><span class="section"><a href="#uml2example_codegen">Code generation</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_codegen_templates">Defining the templates</a></span></dt><dt><span class="section"><a href="#uml2example_codegen_workflow">Defining the workflow</a></span></dt></dl></dd><dt><span class="section"><a href="#uml2example_profiles">Profile Support</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_profiles_define">Defining a Profile</a></span></dt><dt><span class="section"><a href="#uml2example_profile_apply">Applying the Profile</a></span></dt><dt><span class="section"><a href="#uml2example_profiles_codegen">Generating Code</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#xsd_tutorial">11. XSD Tutorial</a></span></dt><dd><dl><dt><span class="section"><a href="#xsd_tutorial_setup">Setup</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_overview">Overview</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_create_project">Step 1: Create a Project</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_metamodel">Step 2: Define a Meta Model using XML Schema</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_model">Step 3: Create a Model using XML</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_template">Step 4: Create a Template using Xpand</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_create_workflow">Step 5: Create a Workflow</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_execute_workflow">Step 6: Execute Workflow aka Generate Code</a></span></dt></dl></dd></dl></div><div class="chapter" title="Chapter 10. UML2 Example"><div class="titlepage"><div><div><h2 class="title"><a name="uml2example"></a>Chapter 10. UML2 Example</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#uml2example_setup_eclipse">Setting up Eclipse</a></span></dt><dt><span class="section"><a href="#uml2example_setup_project">Setting up the project</a></span></dt><dt><span class="section"><a href="#uml2example_create_model">Creating a UML2 Model</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_modelling">Modelling the content</a></span></dt></dl></dd><dt><span class="section"><a href="#uml2example_codegen">Code generation</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_codegen_templates">Defining the templates</a></span></dt><dt><span class="section"><a href="#uml2example_codegen_workflow">Defining the workflow</a></span></dt></dl></dd><dt><span class="section"><a href="#uml2example_profiles">Profile Support</a></span></dt><dd><dl><dt><span class="section"><a href="#uml2example_profiles_define">Defining a Profile</a></span></dt><dt><span class="section"><a href="#uml2example_profile_apply">Applying the Profile</a></span></dt><dt><span class="section"><a href="#uml2example_profiles_codegen">Generating Code</a></span></dt></dl></dd></dl></div><div class="section" title="Setting up Eclipse"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml2example_setup_eclipse"></a>Setting up Eclipse</h2></div></div></div><p>Before you can use Xpand with Eclipse UML2<a name="N12ED7" class="indexterm"></a>, you first have to install the UML2 plugins into your |
| Eclipse installation. (You need at least the 'UML2 End-User' Features. |
| Downloadable from the Eclipse-Update site. Work with: Helios update site, |
| and then browse to <span class="emphasis"><em>Modeling</em></span> and select at least the |
| <span class="emphasis"><em>UML2 Extender SDK</em></span>)</p></div><div class="section" title="Setting up the project"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml2example_setup_project"></a>Setting up the project</h2></div></div></div><p>Create a new Xpand plugin project named |
| <span class="emphasis"><em>xpand.uml2.generator</em></span>. To tell the Xpand Eclipse |
| plugins that this project is a UML2 specific one, you need to configure |
| the Meta Model contributors. You need to add the <span class="emphasis"><em>UML2 |
| profiles</em></span> and the <span class="emphasis"><em>EMF Metamodels</em></span> metamodel |
| contributor<a name="N12EF0" class="indexterm"></a>. The order of profiles is important! The UML2 profiles |
| entry must be first in the list.</p><div class="figure"><a name="uml2example_metamodel_config"></a><p class="title"><b>Figure 1. Configure UML2 profiles metamodel</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/wizard.png" alt="Configure UML2 profiles metamodel"></div></div></div><p><br class="figure-break"></p><p>You have to add the following dependencies to the manifest file: |
| </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="classname">org.eclipse.xtend.typesystem.uml2</code></p></li></ul></div></div><div class="section" title="Creating a UML2 Model"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml2example_create_model"></a>Creating a UML2 Model</h2></div></div></div><p>You start by defining a UML2 model, i.e. an instance of the UML2 |
| metamodel. Inside the project, in the source folder, you create a UML2 |
| model that you should call <code class="filename">example.uml</code> (after |
| pressig<span class="emphasis"><em> Next></em></span>).</p><div class="figure"><a name="uml2example_create_model_1"></a><p class="title"><b>Figure 2. Creating a new UML2 model</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/createUMLModel.png" alt="Creating a new UML2 model"></div></div></div><br class="figure-break"><p>On the last page of the wizard you have to select the model object. |
| Make sure its a <span class="emphasis"><em>Model</em></span>, not a |
| <span class="emphasis"><em>Profile</em></span>. </p><div class="figure"><a name="uml2example_select_modelobject"></a><p class="title"><b>Figure 3. Selecting the Model object</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/modelobject.png" alt="Selecting the Model object"></div></div></div><p><br class="figure-break"></p><div class="section" title="Modelling the content"><div class="titlepage"><div><div><h3 class="title"><a name="uml2example_modelling"></a>Modelling the content</h3></div></div></div><p>You should then build a model that looks somewhat like this: |
| </p><div class="figure"><a name="uml2example_examplemodel"></a><p class="title"><b>Figure 4. Example model</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/exampleModel.png" alt="Example model"></div></div></div><p><br class="figure-break"></p><p>By the way, if you rename the <code class="filename">.uml</code> file to |
| <code class="filename">.ecore</code>, you can edit the model using the ecore |
| editors. To inspect the model, they provide a somewhat better view, so |
| you might try!</p></div></div><div class="section" title="Code generation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml2example_codegen"></a>Code generation</h2></div></div></div><div class="section" title="Defining the templates"><div class="titlepage"><div><div><h3 class="title"><a name="uml2example_codegen_templates"></a>Defining the templates</h3></div></div></div><p>Inside the source folder of our project, create a |
| <code class="filename">templates</code> package. Inside that package folder, |
| create a template file <code class="filename">Root.xpt</code> that has the |
| following content. First, we define the entry template that is called |
| <code class="classname">Root</code>. Since we expect a UML model element to be |
| the top element to the model, we define it for |
| <code class="classname">uml::Model</code>. Note the use of the |
| <code class="classname">uml</code> Namespace prefix, as defined in the UML2 |
| metamodel. Inside that template, we iterate over all owned elements of |
| type <code class="classname">uml::Package</code> in the model and expand a |
| template for the packages defined in it.</p><pre class="programlisting">«DEFINE Root FOR uml::Model» |
| «EXPAND PackageRoot FOREACH allOwnedElements().typeSelect(uml::Package)» |
| «ENDDEFINE» |
| </pre><p>In the package template, we again iterate over all owned elements |
| and call a template that handles classes. Although we only have classes |
| in that package we could not rely on this in general. The package may |
| contain any other packageable element, so we need to filter classes |
| using <code class="methodname">typeSelect()</code>.</p><pre class="programlisting">«DEFINE PackageRoot FOR uml::Package» |
| «EXPAND ClassRoot FOREACH ownedType.typeSelect(uml::Class)» |
| «ENDDEFINE» |
| </pre><p>This template handles classes. It opens a file that has the same |
| name as the class, suffixed by <code class="filename">.java</code>. Into that |
| file, we generate an empty class body.</p><pre class="programlisting">«DEFINE ClassRoot FOR uml::Class» |
| «FILE name+".java"» |
| public class «name» {} |
| «ENDFILE» |
| «ENDDEFINE»</pre></div><div class="section" title="Defining the workflow"><div class="titlepage"><div><div><h3 class="title"><a name="uml2example_codegen_workflow"></a>Defining the workflow</h3></div></div></div><p>In order to generate code, we need a workflow definition. Here is |
| the workflow file; you should put it into the source folder. The file |
| should be generally understandable if you read the Getting Started |
| chapter.</p><pre class="programlisting"><?xml version="1.0" encoding="ISO-8859-1"?> |
| <workflow> |
| </pre><p>You need to setup the UML2 stuff (registering URI maps, Factories, |
| etc.). This can be done declaring a bean in before of the |
| <code class="classname">XmiReader</code><a name="N12F92" class="indexterm"></a> component:</p><pre class="programlisting"><bean class="org.eclipse.emf.mwe.utils.StandaloneSetup" > |
| <platformUri value=".."/> |
| </bean> |
| |
| <!-- load model and store it in slot 'model' --> |
| <component class="org.eclipse.emf.mwe.utils.Reader"> |
| <uri value="platform:/resource/xpand.uml2.generator/src/example.uml" /> |
| <modelSlot value="model" /> |
| </component></pre><p>The <code class="classname">XmiReader</code> reads the model and stores |
| the content (a list containing the model element) in a slot named |
| '<code class="varname">model</code>'. As usual, you might want to clean the target |
| directory<a name="N12FA1" class="indexterm"></a>.</p><pre class="programlisting"><component id="dirCleaner" |
| class="org.eclipse.emf.mwe.utils.DirectoryCleaner" |
| directory="src-gen"/></pre><p>and in the generator we also configure the UML2 |
| metamodel<a name="N12FAA" class="indexterm"></a>.</p><pre class="programlisting"> <component id="generator" class="org.eclipse.xpand2.Generator" skipOnErrors="true"> |
| <metaModel class="org.eclipse.xtend.typesystem.uml2.UML2MetaModel"/> |
| <expand value="templates::Root::Root FOR model"/> |
| <fileEncoding value="ISO-8859-1"/> |
| <outlet path="src-gen"> |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| </outlet> |
| </component> |
| </workflow></pre><p>If you run the workflow (by right clicking on the |
| <code class="filename">.mwe</code> file and select <span class="guiicon">Run As</span> → <span class="guimenuitem">MWE workflow</span>) the two Java classes should be generated.</p></div></div><div class="section" title="Profile Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uml2example_profiles"></a>Profile Support</h2></div></div></div><p>Xpand is shipped with a special <span class="emphasis"><em>UML2 profiles</em></span> |
| metamodel implementation. The implementation maps Stereotypes<a name="N12FC5" class="indexterm"></a> to Types and Tagged Values<a name="N12FC9" class="indexterm"></a> to simple properties. It also supports |
| Enumerations<a name="N12FCD" class="indexterm"></a> defined in the profile and Stereotype hierarchies.</p><div class="section" title="Defining a Profile"><div class="titlepage"><div><div><h3 class="title"><a name="uml2example_profiles_define"></a>Defining a Profile</h3></div></div></div><p>To define a profile, you can use a variety of UML2-based modelling |
| tools. Assuming they do actually correctly create profile definitions |
| (which is not always the case, as we had to learn painfully), creating a |
| profile and exporting it correctly is straight forward.</p><p>In this section, we explain the "manual way", which is good for |
| explaining what happens, but completely useless for practical use. You |
| do not want to build models of realistic sizes using the mechanisms |
| explained below.</p><p>You start be creating a new UML2 file (as shown above). In the |
| example we will call it <code class="filename">test.profile.uml</code>. The root |
| element, however, will be a <span class="emphasis"><em>Profile</em></span>, not a |
| <span class="emphasis"><em>Package</em></span>. Don't forget to actually assign a name to |
| the profile! It should be <code class="literal">test</code>, too.</p><p>The created <span class="emphasis"><em>Profile</em></span> we call |
| <code class="literal">test</code>. In our case, we want to make the stereotype be |
| applicable to UML classes – they are defined as part of the UML2 |
| metamodel. So we have to import that metamodel first. So what you do is |
| to select your profile object, and then go to the UML2 Editor menu (in |
| the Eclipse menu bar) and select <span class="emphasis"><em>Profile -> Reference |
| Metaclass</em></span>. Select <code class="classname">uml::Class</code>. Then, |
| add a stereotype to your profile (right mouse click on the profile -> |
| <span class="emphasis"><em>New Child</em></span> -> <span class="emphasis"><em>Owned |
| Stereotype</em></span> -> <span class="emphasis"><em>Stereotype).</em></span> Now you |
| can define your stereotype: select <span class="emphasis"><em>Stereotype -> Create |
| Extension</em></span> from the UML2 Editor menu. Select |
| <code class="classname">uml::Class</code>. This should lead to the following |
| model. Save it and you are done with the profile definition.</p><div class="figure"><a name="uml2example_profile"></a><p class="title"><b>Figure 5. Modelling a Profile</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/profile.png" alt="Modelling a Profile"></div></div></div><br class="figure-break"></div><div class="section" title="Applying the Profile"><div class="titlepage"><div><div><h3 class="title"><a name="uml2example_profile_apply"></a>Applying the Profile</h3></div></div></div><p>To make any use of the profile, we have to apply it to some kind |
| of model. To do that, we copy the <code class="filename">example.uml</code> model |
| to a <code class="filename">example-profiled.uml</code>. We then open that file |
| and load a resource, namely the profile we just defined. This then looks |
| somewhat like this:</p><div class="figure"><a name="uml2example_profileApp1"></a><p class="title"><b>Figure 6. Loading the Profile</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/profileApp1.gif" alt="Loading the Profile"></div></div></div><br class="figure-break"><p>Now, to make the following stuff work, you first have to select |
| the profile and select the <span class="emphasis"><em>Profile -> Define</em></span> |
| operation from the UML2 Editor menu. This creates all kinds of |
| additional model elements, about which you should not care for the |
| moment.</p><p>Now, finally, you can select your <code class="literal">cars</code> package |
| (the one from the example model) and select <span class="emphasis"><em>Package -> |
| Apply Profile</em></span> from the UML2 Editor menu. Select your test |
| profile to be applied.</p><p>For the purpose of this example, you should now apply the test |
| stereotype to the <code class="classname">PersonCar</code> class. Select the |
| class, and the select <span class="emphasis"><em>Element -> Apply |
| Stereotype</em></span> from the UML2 Editor menu. This should result in |
| the following model:</p><div class="figure"><a name="uml2example_profileApp2"></a><p class="title"><b>Figure 7. Defining the Profile</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/uml2_example/profileApp2.png" alt="Defining the Profile"></div></div></div><br class="figure-break"></div><div class="section" title="Generating Code"><div class="titlepage"><div><div><h3 class="title"><a name="uml2example_profiles_codegen"></a>Generating Code</h3></div></div></div><p>Note that all the stuff above was not in any way related to Xpand, |
| it was just the "bare bones" means of creating and applying a profile to |
| a UML2 model. Having an UML2 tool capable of storing models as EMF UML2 |
| XMI<a name="N13055" class="indexterm"></a> would make the creation of the model far more easier. |
| Since we cannot assume which UML2 tool you are using this tutorial shows |
| you this way, which would always work without further tooling |
| installed.</p><p>There are two things we have to change: The workflow |
| (specifically, the configuration of the generator component) needs to |
| know about the profile, and the template needs to generate different |
| code if a class has the test stereotype applied. Let us look at the |
| second aspect first. Here is the modified template (in |
| <code class="filename">RootWithProfile.xpt</code>):</p><pre class="programlisting">«DEFINE Root FOR uml::Model» |
| «EXPAND PackageRoot FOREACH allOwnedElements().typeSelect(uml::Package)» |
| «ENDDEFINE» |
| |
| «DEFINE PackageRoot FOR uml::Package» |
| «EXPAND ClassRoot FOREACH ownedType.typeSelect(uml::Class)» |
| «ENDDEFINE» |
| |
| «DEFINE ClassRoot FOR uml::Class» |
| «FILE name+".java"» |
| public class «name» {} |
| «ENDFILE» |
| «ENDDEFINE» |
| |
| «DEFINE ClassRoot FOR test::test» |
| «FILE name+".java"» |
| public class «name» {} // stereotyped |
| «ENDFILE» |
| «ENDDEFINE» </pre><p>As you can see, <span class="bold"><strong>the stereotype acts just |
| like a type</strong></span>, and even the polymorphic dispatch between the |
| base type (<code class="classname">uml::Class</code>) and the stereotype |
| works!</p><p>Adapting the workflow file is also straight forward |
| (<code class="filename">workflowWithProfile.mwe</code>). Here is the modified |
| model component with the new model |
| <code class="filename">example-profiled.uml</code> and a extended setup:</p><pre class="programlisting"><?xml version="1.0"?> |
| <workflow> |
| <!-- set up EMF for standalone execution --> |
| <bean class="org.eclipse.emf.mwe.utils.StandaloneSetup" platformUri=".." /> |
| |
| <!-- prepare for performing uml --> |
| <bean class="org.eclipse.xtend.typesystem.uml2.Setup" standardUML2Setup="true" /> |
| |
| <!--UML2 Profile - Metamodell--> |
| <bean id="mm_profile" class="org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel"> |
| <profile value="platform:/resource/xpand.uml2.generator/src/test.profile.uml"/> |
| </bean> |
| |
| <!-- load model and store it in slot 'model' --> |
| <component class="org.eclipse.emf.mwe.utils.Reader"> |
| <uri value="platform:/resource/xpand.uml2.generator/src/example-profiled.uml" /> |
| <modelSlot value="model" /> |
| </component></pre><p>And here is the modified generator component:</p><pre class="programlisting"><component id="generator" class="org.eclipse.xpand2.Generator" skipOnErrors="true"> |
| <metaModel idRef="mm_profile"/> |
| <expand value="templates::Root::Root FOR model"/> |
| <fileEncoding value="ISO-8859-1"/> |
| <outlet path="src-gen"> |
| <postprocessor class="org.eclipse.xpand2.output.JavaBeautifier"/> |
| </outlet> |
| </component> |
| </workflow></pre><p>The only thing, we have to do is to add a new metamodel that |
| references the profile we just created.</p></div></div></div><div class="chapter" title="Chapter 11. XSD Tutorial"><div class="titlepage"><div><div><h2 class="title"><a name="xsd_tutorial"></a>Chapter 11. XSD Tutorial</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#xsd_tutorial_setup">Setup</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_overview">Overview</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_create_project">Step 1: Create a Project</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_metamodel">Step 2: Define a Meta Model using XML Schema</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_model">Step 3: Create a Model using XML</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_template">Step 4: Create a Template using Xpand</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_create_workflow">Step 5: Create a Workflow</a></span></dt><dt><span class="section"><a href="#xsd_tutorial_execute_workflow">Step 6: Execute Workflow aka Generate Code</a></span></dt></dl></div><p>This tutorial shows how XML and XML Schemas Definitions (XSD) can be |
| used to generate software. It illustrates how XML files are treated as |
| models, XSDs as meta models and how this integrates with Xpand. This |
| tutorial is an introduction, for in-depth details see <a class="xref" href="#xsd_reference" title="Chapter 9. XSD Adapter">Chapter 9, <i>XSD Adapter</i></a>.</p><div class="section" title="Setup"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_setup"></a>Setup</h2></div></div></div><p>XSD support for Xpand comes with Xpand 0.7.2 or later. Make sure the |
| following plugins are installed as well:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>XSD - XML Schema Definition Runtime ( <a class="ulink" href="http://www.eclipse.org/xsd/" target="_new">http://www.eclipse.org/xsd/</a>, |
| available via Ganymede Update Site)</p></li><li class="listitem"><p>Web Tools Platform (WTP) (WTP is not required to use Xpand XSD |
| support, but helpful, as its provides a nice XML Schema editor and a |
| schema-aware XML editor. (<a class="ulink" href="http://www.eclipse.org/webtools/" target="_new">http://www.eclipse.org/webtools/</a> |
| , available via Ganymede Update Site)</p></li></ul></div></div><div class="section" title="Overview"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_overview"></a>Overview</h2></div></div></div><p>This tutorial explains how you can do code generation with Xtend and |
| Xpand, using XML Schema Definitions as meta models and XML files as |
| models. To keep things easy, the introduced example is a minimalistic one. |
| A text file is generated from contents specified in XML. The general |
| concept of models, meta models and why and when code generation is useful, |
| is not explained. At the end, a deeper view under the hood is taken to |
| understand how XML Schemas are transformed to EMF Ecore models, and which |
| flexibilities/restrictions this approach provides.</p><p>All source files listed within this tutorial are also available as |
| an example project wich can be imported into the Eclipse workspace by |
| running <span class="emphasis"><em>"File" / "New" / "Example..." / "Xpand/Xtend Examples |
| using an XSD Meta Model" / "M2T custom XML to Text via Xpand (minimal |
| Example)"</em></span>. This will create the project |
| <code class="classname">org.eclipse.xpand.examples.xsd.m2t.minimal</code> project |
| in your workspace. This minimal example is based on "<span class="emphasis"><em>M2T custom |
| XML to Java via Xpand</em></span>" |
| (<code class="classname">org.eclipse.xpand.examples.xsd.m2t.xml2javawizard</code>) |
| which is more comprehensive and recommended for further reading.</p><p>To generate code from XML files with Xpand, at least files of the |
| following four types are needed:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Meta Model ( <code class="filename">metamodel.xsd</code> )</p></li><li class="listitem"><p>Model ( <code class="filename">model.xml</code> )</p></li><li class="listitem"><p>Xpand Template ( <code class="filename">template.xpt</code> )</p></li><li class="listitem"><p>MWE Workflow ( <code class="filename">workflow.mwe</code> )</p></li></ul></div><div class="figure"><a name="xsd_tutorial_xsd_project"></a><p class="title"><b>Figure 1. Minimalistic Xpand XSD Project</b></p><div class="figure-contents"><div class="mediaobject"><img src="xsd_tutorial/workspace-minidemo.png" alt="Minimalistic Xpand XSD Project"></div></div></div><br class="figure-break"></div><div class="section" title="Step 1: Create a Project"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_create_project"></a>Step 1: Create a Project</h2></div></div></div><p>To create a Project, create an ordinary Xtend/Xpand-Project. This is |
| done in Eclipse by changing to the Xtend/Xpand perspective and clicking on |
| <span class="emphasis"><em>"File" / "New" / "Xtend/Xpand Project"</em></span>. After |
| entering a name for the project it is created.</p><p>After the project is created, support for XSD meta models needs to |
| be activated. Click with your right mouse button on the project and open |
| the properties window. Then go to the "Xpand/Xtend" page, |
| "<span class="emphasis"><em>enable project specific settings</em></span>" and activate the |
| "<span class="emphasis"><em>XSD Metamodels</em></span>" checkbox. There is no need to leave |
| support for any other meta models activated, except you are sure that you |
| want to use one of them, too. <a class="xref" href="#xsd_tutorial_project_properties_mm" title="Figure 2. Activate XSD Meta Model Support for Project">Figure 2, “Activate XSD Meta Model Support for Project”</a> shows how the |
| configuration is supposed to look like.</p><div class="figure"><a name="xsd_tutorial_project_properties_mm"></a><p class="title"><b>Figure 2. Activate XSD Meta Model Support for Project</b></p><div class="figure-contents"><div class="mediaobject"><img src="xsd_tutorial/project-properties-mm.png" alt="Activate XSD Meta Model Support for Project"></div></div></div><br class="figure-break"><p>Then, <code class="classname">org.eclipse.xtend.typesystem.xsd</code> needs |
| to be added to the project's dependencies. To do so open the file |
| <code class="filename">META-INF/MANIFEST.MF</code> from your project and navigate |
| to the "Dependencies"-tab. |
| <code class="classname">org.eclipse.xtend.typesystem.xsd</code> needs to be added |
| to the list of "Required Plug-ins", as it is shown in <a class="xref" href="#xsd_tutorial_project_dependencies" title="Figure 3. Required Dependencies for Project">Figure 3, “Required Dependencies for Project”</a> .</p><div class="figure"><a name="xsd_tutorial_project_dependencies"></a><p class="title"><b>Figure 3. Required Dependencies for Project</b></p><div class="figure-contents"><div class="mediaobject"><img src="xsd_tutorial/project-dependencies.png" alt="Required Dependencies for Project"></div></div></div><br class="figure-break"></div><div class="section" title="Step 2: Define a Meta Model using XML Schema"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_metamodel"></a>Step 2: Define a Meta Model using XML Schema</h2></div></div></div><p>In case you are not going to use an existing XML Schema Definition, |
| you can create a new a new one like described below. These steps make use |
| of the Eclipse Web Tools Platform (WTP) to have fancy editors.</p><p>In Eclipse, click on <span class="emphasis"><em>"File", "New", "Other..."</em></span> |
| and choose <span class="emphasis"><em>"XML Schema"</em></span> from category "XML". Select |
| the project's "src" folder and specify a filename. Clicking on "finish" |
| creates an empty XSD file. It is important that the XSD file is located |
| somewhere within the project's classpath.</p><p>This XML Schema consists of two complex data types, which contain |
| some elements and attributes. "complex" in the XSD terminology means that |
| as opposed to simple data types that they can actually have sub-elements |
| and/or attributes. This example is too minimalistic to do anything |
| useful.</p><p>The complex Type <code class="classname">Wizard</code> contains the elements |
| <code class="classname">startpage</code> , <code class="classname">name</code> , |
| <code class="classname">welcometext</code> , and <code class="classname">choicepage</code> |
| . Except for <code class="classname">choicepage</code> all elements have to |
| contain strings, whereas the string of <code class="classname">startpage</code> |
| must be a valid id of any <code class="classname">ChoicePage</code> . The complex |
| type <code class="classname">ChoicePage</code> just contains an |
| <code class="classname">id</code> and a <code class="classname">name</code> . For Xpand it |
| does not make any difference if something is modeled as an XML-attribute |
| or XML-element. Just the datafield's type defines how Xpand treats the |
| value.</p><p>To get an overview how schemas can be used by the Xpand XSD Adapter, |
| see <a class="xref" href="#xsd_reference_declare_xsd" title="How to declare XML Schemas">the section called “How to declare XML Schemas”</a></p><p>Internally, the Xpand XSD Adapter transforms the XSD model to an |
| Ecore model which Xpand can use like any other Ecore model. For more |
| information about that, see <a class="xref" href="#xsd_reference_xsd2ecore" title="Behind the scenes: Transforming XSD to Ecore">the section called “Behind the scenes: Transforming XSD to Ecore”</a></p><div class="figure"><a name="xsd_tutorial_xsd_editor"></a><p class="title"><b>Figure 4. WTP Schema Editor</b></p><div class="figure-contents"><div class="mediaobject"><img src="xsd_tutorial/xsd-editor.png" alt="WTP Schema Editor"></div></div></div><br class="figure-break"><pre class="programlisting"><?xml version="1.0" encoding="UTF-8"?> |
| <schema xmlns="http://www.w3.org/2001/XMLSchema" |
| targetNamespace="http://www.example.org/wizard" |
| xmlns:tns="http://www.example.org/wizard" |
| elementFormDefault="qualified"> |
| |
| <complexType name="Wizard"> |
| <sequence> |
| <element name="startpage" type="IDREF" /> |
| <element name="name" type="string" /> |
| <element name="welcometext" type="string" /> |
| <element name="choicepage" type="tns:ChoicePage" /> |
| </sequence> |
| </complexType> |
| |
| <complexType name="ChoicePage"> |
| <sequence> |
| <element name="title" type="string" /> |
| </sequence> |
| <attribute name="id" type="ID" /> |
| </complexType> |
| |
| <element name="wizard" type="tns:Wizard" /> |
| </schema></pre></div><div class="section" title="Step 3: Create a Model using XML"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_model"></a>Step 3: Create a Model using XML</h2></div></div></div><p>As the title says, data in XML-Format will be the model. And as a |
| model has to be valid according to a meta model, the XML files must be |
| valid according to the XSD.</p><p>In case you are not going to use an existing XML file, you can |
| create a new one like described below. These steps require the Eclipse Web |
| Tools Platform (WTP) to be installed.</p><p>In Eclipse, click on <span class="emphasis"><em>"File", "New", "Other..."</em></span> |
| and choose <span class="emphasis"><em>"XML"</em></span> from category |
| <span class="emphasis"><em>"XML"</em></span>. After specifying a filename within folder |
| "src" choose <span class="emphasis"><em>"create XML file from an XML Schema"</em></span> and |
| select you XML Schema Definition file. Telling Eclipse which schema to use |
| has three advantages: Eclipse validates XML files, there is meta model |
| aware code completion while editing and Eclipse creates a |
| <span class="property">xsi:schemaLocation</span>-attribute which tells anyone who |
| reads the XML file where the schema file is located. This tutorial does |
| not use the <span class="property">xsi:schemaLocation</span>-attribute and |
| introduces the schema file in the MWE workflow instead. For all possible |
| ways see <a class="xref" href="#xsd_reference_declare_xsd" title="How to declare XML Schemas">the section called “How to declare XML Schemas”</a> . It is important |
| that the XML file is located somewhere within the project's |
| classpath.</p><pre class="programlisting"><?xml version="1.0" encoding="UTF-8"?> |
| <wizard xmlns="http://www.example.org/wizard"> |
| <startpage>start</startpage> |
| <name>My Example Setup</name> |
| <welcometext>Welcome to this little demo application.</welcometext> |
| <choicepage id="start"> |
| <title>Wizard Page One</title> |
| </choicepage> |
| </wizard></pre></div><div class="section" title="Step 4: Create a Template using Xpand"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_template"></a>Step 4: Create a Template using Xpand</h2></div></div></div><p>Create an ordinary Xpand Template file: Being in the Xpand/Xtend |
| perspective, go to <span class="emphasis"><em>"File", "New", "xPand template"</em></span>. |
| The Xpand language itself is explained by several other Xpand documents. |
| Having XSD meta model support activated like described in <a class="xref" href="#xsd_tutorial_create_project" title="Step 1: Create a Project">the section called “Step 1: Create a Project”</a> , Xpand scans and watches all |
| it's projects for suitable meta models. Based on what is found, the Xpand |
| editor provides meta model aware code completion.</p><p>This example imports "<code class="classname">metamodel</code>" at the |
| beginning, which refers to a file called |
| <code class="filename">metamodel.xsd</code> that you have created within the |
| project's classpath in <a class="xref" href="#xsd_tutorial_metamodel" title="Step 2: Define a Meta Model using XML Schema">the section called “Step 2: Define a Meta Model using XML Schema”</a> . The |
| define-block can be understood as a function named |
| "<code class="methodname">Root</code>" which takes one object of type |
| <code class="classname">metamodel::Wizard</code> as a parameter. This is the meta |
| model's type for the XML's root object. The file-block creates a file |
| named <code class="filename">wizard.txt</code> and writes the text that is |
| surrounded by the file-block into the file. <code class="classname">name</code> , |
| <code class="classname">welcometext</code> and |
| <code class="classname">choicepage.title</code> are elements or attributes defined |
| in the XSD meta model. Their values are stored within the XML file and |
| this templates inserts them into the generated ( |
| <code class="filename">wizard.txt</code> ) file.</p><pre class="programlisting">«IMPORT metamodel» |
| |
| «DEFINE Root FOR metamodel::Wizard» |
| «FILE "wizard.txt"» |
| Name: «name» |
| Welcometext: «welcometext» |
| First Page Title: «choicepage.title» |
| «ENDFILE» |
| «ENDDEFINE»</pre></div><div class="section" title="Step 5: Create a Workflow"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_create_workflow"></a>Step 5: Create a Workflow</h2></div></div></div><p>The workflow ties together model, meta model and templates and |
| defines the process of how to generate code.</p><p>To create a new workflow file, switch to the Xpand/Xtend |
| perspective, click on <span class="emphasis"><em>"File", "New" and "Workflow |
| file"</em></span>. After specifying a folder and a filename an empty |
| workflow is created.</p><p>The minimalistic approach consists of two steps:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Read the Model: This is done by <code class="classname"> |
| org.eclipse.xtend.typesystem.xsd.XMLReader </code> . It needs |
| exactly one <code class="classname">uri</code> element which defines the XML |
| file. A further nested element of type <code class="classname"> |
| org.eclipse.xtend.typesystem.xsd.XSDMetaModel </code> tells the |
| <code class="classname">XMLReader</code> which metamodel to use. |
| <code class="classname">XSDMetaModel</code> can contain multiple |
| <code class="classname">schemaFile</code> elements. How the schemas are used |
| for the XML file is determined based on the declared namespaces. |
| <code class="classname">modelSlot</code> defines a location where the model is |
| stored internally, this is like a variable name which becomes |
| important if you want to handle multiple models within the same |
| workflow.</p></li><li class="listitem"><p>Generate Code: This part just does the regular code generation |
| using Xpand and is not specific to the Xpand XSD Adapter at all. The |
| generator <code class="classname"> org.eclipse.xpand2.Generator </code> needs |
| to know which meta model to use. This example references the |
| previously declared one. The <code class="classname">expand</code> element |
| tells the generator to call the definition named |
| <code class="methodname">Root</code> within file |
| <code class="filename">template.xpt</code> using the contents of slot |
| <code class="varname">model</code> as parameter. Element |
| <code class="classname">outlet</code> defines where to store the generates |
| files.</p></li></ol></div><pre class="programlisting"><workflow> |
| <component class="org.eclipse.xtend.typesystem.xsd.XMLReader"> |
| <modelSlot value="model" /> |
| <uri value="model.xml" /> |
| <metaModel id="mm" |
| class="org.eclipse.xtend.typesystem.xsd.XSDMetaModel"> |
| <schemaFile value="metamodel.xsd" /> |
| </metaModel> |
| </component> |
| <component class="org.eclipse.xpand2.Generator"> |
| <metaModel idRef="mm" /> |
| <expand value="template::Root FOR model" /> |
| <outlet path="src-gen" /> |
| </component> |
| </workflow></pre></div><div class="section" title="Step 6: Execute Workflow aka Generate Code"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="xsd_tutorial_execute_workflow"></a>Step 6: Execute Workflow aka Generate Code</h2></div></div></div><p>Before you actually execute the workflow, or in case of errors, you |
| can use <a class="xref" href="#xsd_tutorial_minidemo_all" title="Figure 5. Files of this Tutorial">Figure 5, “Files of this Tutorial”</a> to double check your |
| files.</p><div class="figure"><a name="xsd_tutorial_minidemo_all"></a><p class="title"><b>Figure 5. Files of this Tutorial</b></p><div class="figure-contents"><div class="mediaobject"><img src="xsd_tutorial/minidemo-all.png" alt="Files of this Tutorial"></div></div></div><br class="figure-break"><p>To execute the workflow, click with your right mouse button on the |
| workflow file and choose <span class="emphasis"><em>"Run As", "MWE Workflow"</em></span>, as |
| it is shown in <a class="xref" href="#xsd_tutorial_execute_workflow" title="Step 6: Execute Workflow aka Generate Code">the section called “Step 6: Execute Workflow aka Generate Code”</a> .</p><div class="figure"><a name="xsd_tutorial_launch_workflow"></a><p class="title"><b>Figure 6. Execute Workflow</b></p><div class="figure-contents"><div class="mediaobject"><img src="xsd_tutorial/execute-workflow.png" alt="Execute Workflow"></div></div></div><br class="figure-break"><p>When executing the workflow, this output is supposed to appear in |
| Eclipse's Console View. If that View does not pop up automatically, you |
| can reach it via <span class="emphasis"><em>"Window", "Show View", |
| "Console"</em></span>.</p><pre class="programlisting">May 25, 2009 3:09:35 PM org.eclipse.emf.mwe.core.WorkflowRunner prepare |
| INFO: running workflow: /Users/meysholdt/Eclipse/workspace-3.5-M7/org.eclipse.xpand.examples.xsd.m2t.minimal/src/xsd/m2t/minimal/minimal.mwe |
| May 25, 2009 3:09:35 PM org.eclipse.emf.mwe.core.WorkflowRunner prepare |
| INFO: |
| May 25, 2009 3:09:36 PM org.eclipse.xtend.typesystem.xsd.XSDMetaModel addSchemaFile |
| INFO: Loading XSDSchema from 'xsd/m2t/minimal/metamodel.xsd' |
| May 25, 2009 3:09:37 PM org.eclipse.xtend.typesystem.xsd.builder.OawXSDEcoreBuilder initEPackage |
| INFO: Creating EPackage 'metamodel' from XSDSchema 'file:/.../bin/xsd/m2t/minimal/metamodel.xsd' (http://www.example.org/wizard) |
| May 25, 2009 3:09:37 PM org.eclipse.emf.mwe.core.container.CompositeComponent internalInvoke |
| INFO: XMLReader: Loading XML file xsd/m2t/minimal/model.xml |
| May 25, 2009 3:09:37 PM org.eclipse.emf.mwe.core.container.CompositeComponent internalInvoke |
| INFO: Generator: generating 'xsd::m2t::minimal::template::Root FOR model' => src-gen |
| May 25, 2009 3:09:38 PM org.eclipse.xpand2.Generator invokeInternal2 |
| INFO: Written 1 files to outlet [default](src-gen) |
| May 25, 2009 3:09:38 PM org.eclipse.emf.mwe.core.WorkflowRunner executeWorkflow |
| INFO: workflow completed in 657ms! |
| </pre><p>After code generation, there is a file called |
| <code class="filename">wizard.txt</code> within the <code class="filename">src-gen</code> |
| folder. Its contents is supposed to look like shown below. You should be |
| able to recognize the structure you've defined within the template file |
| and the contents from your XML model.</p><pre class="programlisting">Name: My Example Setup |
| Welcometext: Welcome to this little demo application. |
| First Page Title: Wizard Page One</pre></div></div></div><div class="index" title="Index"><div class="titlepage"><div><div><h2 class="title"><a name="N1324A"></a>Index</h2></div></div></div><div class="index"><div class="indexdiv"><h3>Symbols</h3><dl><dt>.chk, <a class="indexterm" href="#Check_language_description">Description of the Check language</a></dt><dt>.xpt, <a class="indexterm" href="#xpand_reference_template_files_and_ecoding">Template files and encoding</a></dt><dt>*.ext, <a class="indexterm" href="#N10DE7">Xtend files</a></dt></dl></div><div class="indexdiv"><h3>A</h3><dl><dt>Advice, <a class="indexterm" href="#N1107E">Aspect-Oriented Programming in |
| Xtend</a></dt><dt>AdviceContext, <a class="indexterm" href="#N110D9">Proceeding</a></dt><dt>AOP, <a class="indexterm" href="#N1107E">Aspect-Oriented Programming in |
| Xtend</a>, <a class="indexterm" href="#xpand_reference_aspect-oriented_programming_in_xpand">Aspect-Oriented Programming in |
| Xpand</a></dt><dd><dl><dt>Join point, <a class="indexterm" href="#xpand_reference_join_point_and_cut_syntax">Join Point and Point Cut Syntax</a></dt><dt>Point cut, <a class="indexterm" href="#xpand_reference_join_point_and_cut_syntax">Join Point and Point Cut Syntax</a></dt><dt>Workflow, <a class="indexterm" href="#aop_template_example_workflow_file">Workflow File</a></dt><dt>Xpand, <a class="indexterm" href="#aop_template_introduction">Example for using Aspect-Oriented Programming in |
| Xpand</a></dt></dl></dd><dt>AROUND, <a class="indexterm" href="#xpand_reference_aspect-oriented_programming_in_xpand">Aspect-Oriented Programming in |
| Xpand</a>, <a class="indexterm" href="#aop_template_example_templates">Templates</a>, <a class="indexterm" href="#aop_template_more_ao">More Aspect Orientation</a></dt><dt>Aspect-Oriented Programming, <a class="indexterm" href="#N1107E">Aspect-Oriented Programming in |
| Xtend</a></dt></dl></div><div class="indexdiv"><h3>B</h3><dl><dt>Boolean type, <a class="indexterm" href="#r10_builtintypes_simple">Simple types (Data types)</a></dt><dt>Built-in type, <a class="indexterm" href="#r10_builtintypes">Built-In Types</a></dt><dd><dl><dt>Collection types, <a class="indexterm" href="#r10_builtintypes_collections">Collection types</a></dt><dt>Object, <a class="indexterm" href="#r10_builtintypes_object">Object</a>, <a class="indexterm" href="#r10_expressions_builtin_object">Object </a></dt><dt>Simple type, <a class="indexterm" href="#r10_builtintypes_simple">Simple types (Data types)</a></dt><dt>Void, <a class="indexterm" href="#r10_builtintypes_void">Void</a>, <a class="indexterm" href="#r10_expressions_builtin_object">Object </a></dt></dl></dd></dl></div><div class="indexdiv"><h3>C</h3><dl><dt>cached, <a class="indexterm" href="#N10EC5">Cached Extensions</a></dt><dt>cartridge, <a class="indexterm" href="#xpand_reference_aspect-oriented_programming_in_xpand">Aspect-Oriented Programming in |
| Xpand</a></dt><dt>Casting, <a class="indexterm" href="#r10_expressions_casting">Casting</a></dt><dt>CEND, <a class="indexterm" href="#xpand_reference_protect">PROTECT</a></dt><dt>Check</dt><dd><dl><dt>File extension, <a class="indexterm" href="#Check_language_description">Description of the Check language</a></dt><dt>Language, <a class="indexterm" href="#emf_tutorial_checking_contraints_with_check">Checking Constraints with the Check |
| Language</a>, <a class="indexterm" href="#Check_language_description">Description of the Check language</a></dt></dl></dd><dt>Classpath, <a class="indexterm" href="#xpand_reference_extension">EXTENSION</a></dt><dt>collect, <a class="indexterm" href="#r10_expressions_collection_collect">collect</a>, <a class="indexterm" href="#r10_expressions_collection_collect_shorthand">Shorthand for collect (and more than |
| that)</a></dt><dt>Collection, <a class="indexterm" href="#r10_builtintypes_collections">Collection types</a>, <a class="indexterm" href="#xpand_reference_foreach">FOREACH</a></dt><dt>Collection type, <a class="indexterm" href="#r10_typesystem_collection_typenames">Collection Type Names</a></dt><dt>collection type, <a class="indexterm" href="#xpand_reference_for_vs_foreach">FOR vs. FOREACH</a></dt><dt>Constraint, <a class="indexterm" href="#emf_tutorial_defining_the_constraint">Defining the constraint</a>, <a class="indexterm" href="#Check_language_description">Description of the Check language</a></dt><dt>create, <a class="indexterm" href="#create_extension">Create Extensions (Model Transformation)</a></dt><dt>Create extension, <a class="indexterm" href="#xtend_example_the_transformation">The transformation</a></dt><dt>CSTART, <a class="indexterm" href="#xpand_reference_protect">PROTECT</a></dt></dl></div><div class="indexdiv"><h3>D</h3><dl><dt>DEFINE, <a class="indexterm" href="#xpand_reference_define">DEFINE</a></dt><dt>DirectoryCleaner, <a class="indexterm" href="#uml2example_codegen_workflow">Defining the workflow</a></dt><dt>Dynamic EMF, <a class="indexterm" href="#emf_tutorial_dynamic_emf">Using Dynamic EMF</a></dt></dl></div><div class="indexdiv"><h3>E</h3><dl><dt>EClassifiers, <a class="indexterm" href="#r10_typesystem_typenames">Type Names</a></dt><dt>ELSEIF, <a class="indexterm" href="#xpand_reference_if">IF</a></dt><dt>EMF, <a class="indexterm" href="#emf_tutorial">Getting Started</a></dt><dt>EmfMetaModel, <a class="indexterm" href="#emf_tutorial_templates">Templates</a>, <a class="indexterm" href="#r10_typesystem_typenames">Type Names</a>, <a class="indexterm" href="#emf_metamodel">The EMF Metamodel |
| (org.eclipse.xtend.typesystem.emf.EmfMetaModel)</a></dt><dd><dl><dt>metaModelPackage, <a class="indexterm" href="#emf_tutorial_dynamic_emf">Using Dynamic EMF</a></dt></dl></dd><dt>EMF metamodel, <a class="indexterm" href="#r10_using_different_metamodels">Using different Metamodel implementations (also known as |
| Meta-Metamodels)</a></dt><dt>EMF project, <a class="indexterm" href="#emf_tutorial_creating_emf_project">Creating an EMF project</a></dt><dt>EmfRegistryMetaModel, <a class="indexterm" href="#emfregistry_metamodel">The EMF Registry Metamodel |
| (org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel)</a></dt><dt>EMF UML2 XMI, <a class="indexterm" href="#uml2example_profiles_codegen">Generating Code</a></dt><dt>Encoding, <a class="indexterm" href="#emf_tutorial_setting_generator_project">Setting up the generator project</a> (see File encoding)</dt><dt>ENDIF, <a class="indexterm" href="#xpand_reference_if">IF</a></dt><dt>Enumeration</dt><dd><dl><dt>Literal, <a class="indexterm" href="#r10_expressions_builtin_staticproperties">StaticProperty literals</a></dt></dl></dd><dt>Enumeration (UML2), <a class="indexterm" href="#uml2example_profiles">Profile Support</a></dt><dt>EPackages, <a class="indexterm" href="#r10_typesystem_typenames">Type Names</a></dt><dt>ERROR, <a class="indexterm" href="#xpand_reference_error">ERROR</a></dt><dt>ExecutionContext, <a class="indexterm" href="#N10F22">IExecutionContextAware</a></dt><dt>exists, <a class="indexterm" href="#r10_expressions_collection_exists">exists</a></dt><dt>EXPAND, <a class="indexterm" href="#xpand_reference_expand">EXPAND</a>, <a class="indexterm" href="#xpand_reference_metamodel">Metamodel</a></dt><dt>Expression, <a class="indexterm" href="#r10_expressions_language">Expressions</a></dt><dd><dl><dt>cached, <a class="indexterm" href="#create_extension">Create Extensions (Model Transformation)</a></dt><dt>call, <a class="indexterm" href="#N11023">Calling Extensions From Java</a></dt><dt>chain, <a class="indexterm" href="#r10_expressions_chain">Chain expression</a></dt><dt>create, <a class="indexterm" href="#xtend_example_the_transformation">The transformation</a></dt><dt>if, <a class="indexterm" href="#r10_expressions_if">if expression</a></dt><dt>new, <a class="indexterm" href="#r10_expressions_create">new expression</a></dt><dt>separator, <a class="indexterm" href="#xpand_reference_specifying_a_separator">Specifying a Separator</a></dt><dt>switch, <a class="indexterm" href="#r10_expressions_switch">switch expression</a></dt></dl></dd><dt>Expression language, <a class="indexterm" href="#r10_expressions_language">Expressions</a></dt><dt>Extension, <a class="indexterm" href="#emf_tutorial_extensions">Extensions</a>, <a class="indexterm" href="#N10E26">Extension Import Statement</a></dt><dd><dl><dt>caching, <a class="indexterm" href="#N10EC5">Cached Extensions</a></dt><dt>create, <a class="indexterm" href="#create_extension">Create Extensions (Model Transformation)</a>, <a class="indexterm" href="#xtend_example_the_transformation">The transformation</a></dt><dt>invocation, <a class="indexterm" href="#N10E50">Extension Invocation</a></dt><dt>Java, <a class="indexterm" href="#N10EF3">Java Extensions</a></dt><dt>private, <a class="indexterm" href="#N10EE0">Private Extensions</a></dt><dt>recursion, <a class="indexterm" href="#N10EB3">Recursion</a></dt></dl></dd><dt>EXTENSION, <a class="indexterm" href="#xpand_reference_extension">EXTENSION</a></dt></dl></div><div class="indexdiv"><h3>F</h3><dl><dt>FILE, <a class="indexterm" href="#xpand_reference_file">FILE</a></dt><dt>File encoding</dt><dd><dl><dt>encoding, <a class="indexterm" href="#xpand_reference_template_files_and_ecoding">Template files and encoding</a>, <a class="indexterm" href="#xpand_reference_encoding">Encoding</a>, <a class="indexterm" href="#xpand_reference_output_configuration">Output configuration</a></dt></dl></dd><dt>File extension</dt><dd><dl><dt>.xpt, <a class="indexterm" href="#xpand_reference_template_files_and_ecoding">Template files and encoding</a></dt></dl></dd><dt>FOR, <a class="indexterm" href="#xpand_reference_for_vs_foreach">FOR vs. FOREACH</a></dt><dt>forAll, <a class="indexterm" href="#r10_expressions_collection_forall">forAll</a></dt><dt>FOREACH, <a class="indexterm" href="#xpand_reference_for_vs_foreach">FOR vs. FOREACH</a></dt></dl></div><div class="indexdiv"><h3>G</h3><dl><dt>Generator</dt><dd><dl><dt>fileEncoding property, <a class="indexterm" href="#xpand_reference_encoding">Encoding</a></dt><dt>Metamodel configuration, <a class="indexterm" href="#xpand_reference_metamodel">Metamodel</a></dt><dt>Workflow component, <a class="indexterm" href="#xpand_reference_generator_workflow_component">Generator Workflow Component</a></dt></dl></dd><dt>Genmodel, <a class="indexterm" href="#emf_tutorial_generate_emf_tooling">Generating the EMF tooling</a></dt><dt>GLOBALVAR, <a class="indexterm" href="#r10_expressions_globalvar">'GLOBALVAR' expression</a></dt><dt>Global variables, <a class="indexterm" href="#r10_expressions_globalvar_workflow">Using GLOBALVARS to configure workflows</a></dt><dt>Guard conditions, <a class="indexterm" href="#Guard_conditions">Guard Conditions</a></dt><dt>Guillemet, <a class="indexterm" href="#emf_tutorial_templates">Templates</a>, <a class="indexterm" href="#xpand_reference_introduction">Xpand2</a>, <a class="indexterm" href="#xpand_reference_encoding">Encoding</a></dt></dl></div><div class="indexdiv"><h3>I</h3><dl><dt>IExecutionContextAware, <a class="indexterm" href="#N10F22">IExecutionContextAware</a></dt><dt>IF, <a class="indexterm" href="#xpand_reference_if">IF</a></dt><dt>import, <a class="indexterm" href="#N10E15">Import Statements</a></dt><dt>IMPORT, <a class="indexterm" href="#xpand_reference_import">IMPORT</a></dt><dt>Integer type, <a class="indexterm" href="#r10_builtintypes_simple">Simple types (Data types)</a></dt><dt>ITERATOR, <a class="indexterm" href="#xpand_reference_foreach">FOREACH</a></dt></dl></div><div class="indexdiv"><h3>J</h3><dl><dt>JavaBeansMetaModel, <a class="indexterm" href="#N11023">Calling Extensions From Java</a></dt><dt>JavaBeansStrategy, <a class="indexterm" href="#N11023">Calling Extensions From Java</a></dt><dt>JavaBeautifier, <a class="indexterm" href="#xpand_reference_javabeautifier">JavaBeautifier</a></dt><dt>Java extension, <a class="indexterm" href="#emf_tutorial_java_extensions">Java Extensions</a>, <a class="indexterm" href="#N10EF3">Java Extensions</a></dt><dt>JavaMetaModel, <a class="indexterm" href="#r10_metamodel_example_java">Example JavaMetaModel</a>, <a class="indexterm" href="#java_metamodel">The Java Metamodel |
| (org.eclipse.internal.xtend.type.impl.java.JavaMetaModel)</a>, <a class="indexterm" href="#N11023">Calling Extensions From Java</a></dt><dt>Join point, <a class="indexterm" href="#N1109F">Join Point and Point Cut Syntax</a>, <a class="indexterm" href="#N110FA">Workflow configuration</a>, <a class="indexterm" href="#xpand_reference_join_point_and_cut_syntax">Join Point and Point Cut Syntax</a></dt><dt>join point, <a class="indexterm" href="#aop_template_example_templates">Templates</a></dt></dl></div><div class="indexdiv"><h3>K</h3><dl><dt>Keyword</dt><dd><dl><dt>Property, <a class="indexterm" href="#N10CD6">Xpand keywords and metamodel properties</a></dt></dl></dd></dl></div><div class="indexdiv"><h3>L</h3><dl><dt>LET, <a class="indexterm" href="#xpand_reference_let">LET</a></dt><dt>List, <a class="indexterm" href="#r10_builtintypes_collections">Collection types</a></dt><dt>Literals, <a class="indexterm" href="#r10_expressions_builtin">Literals and special operators for built-in types</a></dt></dl></div><div class="indexdiv"><h3>M</h3><dl><dt>meta-metamodel, <a class="indexterm" href="#emf_tutorial_generate_emf_tooling">Generating the EMF tooling</a></dt><dt>MetaModel, <a class="indexterm" href="#r10_typesystem_typenames">Type Names</a></dt><dt>Metamodel, <a class="indexterm" href="#r10_metamodel_contributors">Eclipse IDE MetaModelContributors</a>, <a class="indexterm" href="#r10_using_different_metamodels">Using different Metamodel implementations (also known as |
| Meta-Metamodels)</a>, <a class="indexterm" href="#metamodel_reference">Metamodel Reference</a></dt><dd><dl><dt>(non-invasive) extension, <a class="indexterm" href="#Xtend_language">Xtend</a></dt><dt>EMF, <a class="indexterm" href="#emf_metamodel">The EMF Metamodel |
| (org.eclipse.xtend.typesystem.emf.EmfMetaModel)</a></dt><dt>EMF Registry, <a class="indexterm" href="#emfregistry_metamodel">The EMF Registry Metamodel |
| (org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel)</a></dt><dt>Implementing metamodels, <a class="indexterm" href="#implementing_metamodels">Implementing Your Own Metamodel</a></dt><dt>Java, <a class="indexterm" href="#java_metamodel">The Java Metamodel |
| (org.eclipse.internal.xtend.type.impl.java.JavaMetaModel)</a></dt><dt>UML2, <a class="indexterm" href="#uml2_metamodel">The UML2 Metamodel |
| (org.eclipse.xtend.typesystem.uml2.UML2MetaModel)</a>, <a class="indexterm" href="#uml2profile_metamodel">The UML2 Profile Metamodel |
| (org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel)</a></dt><dt>XSD, <a class="indexterm" href="#xsd_metamodel">The XSD Metamodel |
| (org.eclipse.xtend.typesystem.xsd.XSDMetaModel)</a></dt></dl></dd><dt>MetamodelContributor, <a class="indexterm" href="#r10_metamodel_contributors">Eclipse IDE MetaModelContributors</a></dt><dt>Metamodel contributor, <a class="indexterm" href="#uml2example_setup_project">Setting up the project</a></dt><dt>Metamodel implementation, <a class="indexterm" href="#r10_metamodel_implementations">Metamodel Implementations (also known as |
| Meta-Metamodels)</a></dt><dt>Model-to-model transformation, <a class="indexterm" href="#xtend_example_introduction">Model-to-Model transformation with |
| Xtend</a></dt><dt>Model transformation, <a class="indexterm" href="#create_extension">Create Extensions (Model Transformation)</a></dt><dt>Multiple dispatching, <a class="indexterm" href="#r10_expressions_multidispatch">Multi methods (multiple dispatch)</a></dt></dl></div><div class="indexdiv"><h3>N</h3><dl><dt>Namespace</dt><dd><dl><dt>Import, <a class="indexterm" href="#xpand_reference_names">Names</a></dt></dl></dd><dt>Newline, <a class="indexterm" href="#xpand_reference_controlling_generation_of_white_space">Controlling generation of whitespace</a></dt><dt>NoChangesVetoStrategy, <a class="indexterm" href="#N11709">VetoStrategy</a></dt></dl></div><div class="indexdiv"><h3>O</h3><dl><dt>OCL, <a class="indexterm" href="#r10_expressions_language">Expressions</a></dt><dt>ONFILECLOSE, <a class="indexterm" href="#N11325">Lazy evaluation</a></dt><dt>Operation, <a class="indexterm" href="#r10_metamodel_implementations">Metamodel Implementations (also known as |
| Meta-Metamodels)</a></dt><dt>Outlet, <a class="indexterm" href="#xpand_reference_file">FILE</a>, <a class="indexterm" href="#xpand_reference_output_configuration">Output configuration</a></dt></dl></div><div class="indexdiv"><h3>P</h3><dl><dt>Point cut, <a class="indexterm" href="#N1109F">Join Point and Point Cut Syntax</a>, <a class="indexterm" href="#xpand_reference_join_point_and_cut_syntax">Join Point and Point Cut Syntax</a></dt><dt>Polymorphism, <a class="indexterm" href="#N10E66">Type Inference</a>, <a class="indexterm" href="#xpand_reference_define">DEFINE</a></dt><dt>PostProcessor, <a class="indexterm" href="#xpand_reference_beautifier">PostProcessor </a></dt><dt>private, <a class="indexterm" href="#N10EE0">Private Extensions</a></dt><dt>proceed, <a class="indexterm" href="#N110D9">Proceeding</a></dt><dt>ProfileMetaModel, <a class="indexterm" href="#uml2profile_metamodel">The UML2 Profile Metamodel |
| (org.eclipse.xtend.typesystem.uml2.profile.ProfileMetaModel)</a></dt><dt>property, <a class="indexterm" href="#r10_metamodel_implementations">Metamodel Implementations (also known as |
| Meta-Metamodels)</a></dt><dt>PROTECT, <a class="indexterm" href="#xpand_reference_protect">PROTECT</a></dt><dt>Protected region, <a class="indexterm" href="#xpand_reference_protect">PROTECT</a>, <a class="indexterm" href="#xpand_reference_protected_region_configuration">Protected Region Configuration</a></dt><dd><dl><dt>Disable, <a class="indexterm" href="#xpand_reference_protect">PROTECT</a></dt><dt>Enable, <a class="indexterm" href="#xpand_reference_protect">PROTECT</a></dt></dl></dd><dt>prSrcPaths, <a class="indexterm" href="#xpand_reference_protected_region_configuration">Protected Region Configuration</a></dt></dl></div><div class="indexdiv"><h3>R</h3><dl><dt>Real type, <a class="indexterm" href="#r10_builtintypes_simple">Simple types (Data types)</a></dt><dt>Recursive extensions, <a class="indexterm" href="#N10EB3">Recursion</a></dt><dt>Reexport, <a class="indexterm" href="#N10E35">Reexporting Extensions</a></dt><dt>reject, <a class="indexterm" href="#r10_expressions_collection_reject">reject</a></dt><dt>REM, <a class="indexterm" href="#xpand_reference_comments">Comments</a></dt><dt>Return type, <a class="indexterm" href="#N10E66">Type Inference</a></dt></dl></div><div class="indexdiv"><h3>S</h3><dl><dt>select, <a class="indexterm" href="#r10_expressions_collection_select">select</a></dt><dt>SEPARATOR, <a class="indexterm" href="#xpand_reference_specifying_a_separator">Specifying a Separator</a></dt><dt>Set type, <a class="indexterm" href="#r10_builtintypes_collections">Collection types</a></dt><dt>SlotCopier, <a class="indexterm" href="#N12879">SlotCopier</a></dt><dt>SlotListAdder, <a class="indexterm" href="#N128C4">SlotListAdder</a></dt><dt>SlotPrinter, <a class="indexterm" href="#N12913">SlotPrinter</a></dt><dt>sortBy, <a class="indexterm" href="#r10_expressions_collection_sortby">sortBy</a></dt><dt>Stereotype, <a class="indexterm" href="#uml2example_profiles">Profile Support</a></dt><dt>String type, <a class="indexterm" href="#r10_builtintypes_simple">Simple types (Data types)</a></dt><dt>SystemCommand, <a class="indexterm" href="#N12816">SystemCommand</a></dt></dl></div><div class="indexdiv"><h3>T</h3><dl><dt>Tagged value, <a class="indexterm" href="#uml2example_profiles">Profile Support</a></dt><dt>Template</dt><dd><dl><dt>File, <a class="indexterm" href="#xpand_reference_template_files_and_ecoding">Template files and encoding</a>, <a class="indexterm" href="#xpand_reference_define">DEFINE</a></dt><dt>Polymorphism, <a class="indexterm" href="#xpand_reference_define">DEFINE</a></dt></dl></dd><dt>Transformation, <a class="indexterm" href="#xtend_example_the_transformation">The transformation</a></dt><dt>Type</dt><dd><dl><dt>Data type, <a class="indexterm" href="#r10_typesystem">Type System </a></dt><dt>Operation, <a class="indexterm" href="#r10_typesystem_features">Features</a></dt><dt>Parameter, <a class="indexterm" href="#N110C9">Parameter Types</a></dt><dt>Parameterized type, <a class="indexterm" href="#r10_typesystem">Type System </a></dt><dt>Property, <a class="indexterm" href="#r10_typesystem_features">Features</a></dt><dt>Static property, <a class="indexterm" href="#r10_typesystem_features">Features</a>, <a class="indexterm" href="#r10_expressions_builtin_staticproperties">StaticProperty literals</a></dt></dl></dd><dt>Type inference, <a class="indexterm" href="#N10E66">Type Inference</a></dt><dt>typeSelect, <a class="indexterm" href="#r10_expressions_collection_typeselect">typeSelect </a>, <a class="indexterm" href="#xpand_reference_metamodel">Metamodel</a></dt></dl></div><div class="indexdiv"><h3>U</h3><dl><dt>UML2, <a class="indexterm" href="#uml2example_setup_eclipse">Setting up Eclipse</a></dt><dt>UML2MetaModel, <a class="indexterm" href="#uml2_metamodel">The UML2 Metamodel |
| (org.eclipse.xtend.typesystem.uml2.UML2MetaModel)</a>, <a class="indexterm" href="#uml2example_codegen_workflow">Defining the workflow</a></dt></dl></div><div class="indexdiv"><h3>V</h3><dl><dt>VetoStrategy, <a class="indexterm" href="#N11709">VetoStrategy</a></dt></dl></div><div class="indexdiv"><h3>W</h3><dl><dt>Weaving advices, <a class="indexterm" href="#N1107E">Aspect-Oriented Programming in |
| Xtend</a></dt><dt>Whitespace</dt><dd><dl><dt>Omit, <a class="indexterm" href="#xpand_reference_controlling_generation_of_white_space">Controlling generation of whitespace</a></dt></dl></dd><dt>WorkflowComponent, <a class="indexterm" href="#N11067">WorkflowComponent</a></dt></dl></div><div class="indexdiv"><h3>X</h3><dl><dt>XMI, <a class="indexterm" href="#emf_tutorial_defining_metamodel">Defining the (meta)model</a></dt><dt>XMIReader, <a class="indexterm" href="#xmi_reader">The XMI reader |
| (org.eclipse.xtend.typesystem.uml2.profile.ProfilingExtensions.XmiReader)</a></dt><dt>XmiReader, <a class="indexterm" href="#uml2example_codegen_workflow">Defining the workflow</a></dt><dt>XMI reader, <a class="indexterm" href="#xmi_reader">The XMI reader |
| (org.eclipse.xtend.typesystem.uml2.profile.ProfilingExtensions.XmiReader)</a></dt><dt>Xpand</dt><dd><dl><dt>Comments, <a class="indexterm" href="#xpand_reference_comments">Comments</a></dt><dt>Expression statements, <a class="indexterm" href="#xpand_reference_expression_statement">Expression Statement</a></dt><dt>Language, <a class="indexterm" href="#xpand_reference_introduction">Xpand2</a></dt></dl></dd><dt>XpandException, <a class="indexterm" href="#xpand_reference_error">ERROR</a></dt><dt>XSDMetaModel, <a class="indexterm" href="#xsd_metamodel">The XSD Metamodel |
| (org.eclipse.xtend.typesystem.xsd.XSDMetaModel)</a></dt><dt>Xtend, <a class="indexterm" href="#xpand_reference_extension">EXTENSION</a></dt><dd><dl><dt>Comments, <a class="indexterm" href="#N10E05">Comments</a></dt><dt>File extension, <a class="indexterm" href="#N10DE7">Xtend files</a></dt><dt>Language, <a class="indexterm" href="#Xtend_language">Xtend</a></dt></dl></dd><dt>XtendComponent, <a class="indexterm" href="#N11067">WorkflowComponent</a></dt><dd><dl><dt>Advices, <a class="indexterm" href="#N110FA">Workflow configuration</a></dt></dl></dd><dt>XtendFacade, <a class="indexterm" href="#N11023">Calling Extensions From Java</a></dt></dl></div></div></div></div></body></html> |
