Open steghoja opened 2 years ago
look into template feature of Xtext
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:
(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
?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.
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.
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.
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.
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} {
precondition ${precondition}
mode (${mode})
}
</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.
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} { precondition ${precondition} mode (${mode}) } </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 newMode
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.
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?
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.
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
.
A number of model elements in EAST-ADL have mandatory attributes. For instance, the
ModeGroup
has two mandatory attributes:condition
andprecondition
. It would be nice if our code completion could create these attributes automatically.