Provide code templates for common language constructs

[steghoja]

A number of model elements in EAST-ADL have mandatory attributes. For instance, the ModeGroup has two mandatory attributes: condition and precondition. It would be nice if our code completion could create these attributes automatically.

[joerg-holtmann]

look into template feature of Xtext

[joerg-holtmann]

Documentation for template proposals: Xtext template proposals

In commit 1737b27138902eb5c6729e4bfcae3eb39f08b676, I added an exemplary template for the production rule ModeGroup. This MM element / production rule has a mandatory attribute precondition and at least one mandatory nested element Mode, which in turn has another mandatory attribute condition.

This commit is only a basis for discussion, because I find the approach very interesting but immediately many things came to my mind. Before spending the effort on specifying template proposals for the full language, we should discuss at least the following things @Wilson008 @steghoja:

• The templates are very convenient, maybe we should make them more prominent?
• As the templates are very language-dependent and effortful to maintain: How can we generate them, or align them with the GrammarOptimizer? In contrast to the Grammar, they are closely aligned with the instantiated concrete syntax.
• The default auto-completion currently proposes the very many keywords in the small auto-completion window, so that one has to scroll down a lot to the more convenient template proposals. This behavior can be changed probably quite fast as outlined in the Xtext documentation.
• If one specifies a CRLF in the template editor on a Windows machine, an 
 (HTML code for\r) is put into the templates.xml. Does this work on MacOS @steghoja, or do we have to find an HTML code for \n?

[steghoja]

I had a look at this. First of all, we can turn even more things into variables that the user can switch between with tab:

ModeGroup ${shortName} {
    precondition ${precondition};
    Mode ${shortName} {
        condition ${condition};
    }
}

Second of all, breaking the line with carriage return 
 also works under macos. Third of all, as I have stated before, I think this should be easy to generate, similar to our content assist, etc.

[steghoja]

I have been playing with a generator fragment for this. The problem is that we do not want to create a template for each rule, but only for certain ones. The templates we do create should contain some sub-types as well. Right now, I am thinking of having a configuration file that states which rules to turn into a template.

[joerg-holtmann]

I have been playing with a generator fragment for this. The problem is that we do not want to create a template for each rule, but only for certain ones. The templates we do create should contain some sub-types as well. Right now, I am thinking of having a configuration file that states which rules to turn into a template.

Ed Willink seems to think in a similar direction: https://www.eclipse.org/forums/index.php?t=msg&th=1110904&goto=1852790&#msg_1852790. However, we should make sure that the configuration file (or as Ed calls it "some kind of model of template") does not represent a second kind of grammar that we have to maintain.

[steghoja]

Well, if Ed is onboard... ;)

In any case, I mostly thought of a simple structure such as

ModeGroup
    Mode

Going through the grammar, I realised that we don't have a ton of cases like this, though. Most references are optional or prefixed with a keyword. So the structure would mostly tell us which grammar rules not to turn into templates. But maybe we actually want templates for all? I am not sure.

By the way, my commit does not deal with multi-valued references which require parentheses. For instance, the template for HazardousEvent omits the parentheses for useCase. I am sure there's a way to figure out if we need them, though, e.g., based on the multiplicities.

[steghoja]

We need to be smarter here. The current version turns the ModeGroup rule into this template:

<template autoinsert="true" context="org.bumble.eatxt.Eatxt.ModeGroup" deleted="false" description="Template for ModeGroup" enabled="true" name="ModeGroup" id="eastadl22.ModeGroup">
    ModeGroup ${shortName} {&#13;
        precondition ${precondition}&#13;
        mode (${mode})&#13;
    }
</template>

It adds the incorrect mode keyword and the parentheses which are not needed when there is only one mode. It also does not add a new Mode element as Jörg's original suggestion. That means we need to check the keywords and in cases such as this, also recurse into the nested element.

[joerg-holtmann]

We need to be smarter here. The current version turns the ModeGroup rule into this template:

<template autoinsert="true" context="org.bumble.eatxt.Eatxt.ModeGroup" deleted="false" description="Template for ModeGroup" enabled="true" name="ModeGroup" id="eastadl22.ModeGroup">
  ModeGroup ${shortName} {&#13;
      precondition ${precondition}&#13;
      mode (${mode})&#13;
  }
</template>

It adds the incorrect mode keyword and the parentheses which are not needed when there is only one mode. It also does not add a new Mode element as Jörg's original suggestion. That means we need to check the keywords and in cases such as this, also recurse into the nested element.

I committed an initial (yet dirty, particularly regarding indentation) proposal for these nested elements.

[joerg-holtmann]

Next larger issue to solve: Some of the mandatory elements require a closing ;, and some not. How to figure this out and propose the closing ; in the cases where needed?

[joerg-holtmann]

Next larger issue to solve: Some of the mandatory elements require a closing ;, and some not. How to figure this out and propose the closing ; in the cases where needed?

344b8ac: All of the attributes seem to have the ; as delimiter, so just added them.

[joerg-holtmann]

Next issue: Cross-references to existing elements are not proposed correctly, they are proposed like: attribute.name attribute.name, where the second attribute.name should point to an existing element and in most (or all?) cases has to be surrounded by " ". Particularly, the dynamic determination of an existing element will probably not possible in the static templates; here we have to find a different solution that ideally should not result in a parser error.

Example to reproduce: Element VVLog with its cross-reference performedVVProcedure.