Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Eclipse UML Generators/Specification/UserInterface/ConsistencyImprovement"
m (→Launching from applying a nature) |
|||
(31 intermediate revisions by 2 users not shown) | |||
Line 18: | Line 18: | ||
* context menus; | * context menus; | ||
* generation builders; | * generation builders; | ||
− | * properties | + | * properties pages. |
− | + | ||
== Detailed Specification == | == Detailed Specification == | ||
− | === | + | |
+ | === Iteration 1 === | ||
+ | |||
+ | ==== Generation processing ==== | ||
+ | |||
Java and RTSJ generation are launched on UML files and C generation is launched on UML Elements (classes, packages...). | Java and RTSJ generation are launched on UML files and C generation is launched on UML Elements (classes, packages...). | ||
− | ==== | + | ===== '''Configuration''' ===== |
+ | |||
+ | All generations, Java, RTSJ and C, can be specialized using some properties like the generation target folder, the file headers... | ||
+ | Currently, RTSJ and C generation use UML model properties | ||
+ | [[Image:UMLGen-Properties C.png|thumb|center|668px]] | ||
+ | |||
+ | and Java generation defines them in the launcher. | ||
+ | [[Image:UMLGen-Properties Generate Java 1.png|thumb|center|668px]] | ||
+ | |||
+ | |||
+ | For consistency, all generation properties will be accessible from the UML model properties (like RTSJ and C) in a "UML Generators" container. | ||
+ | [[Image:UMLGen-Properties-After.png|thumb|center|668px]] | ||
+ | |||
+ | |||
+ | With this properties, there is only one configuration by generation types. For example, Java generation has only one configuration per UML file. | ||
+ | |||
+ | Also, for Java generation, there is no synchronization between configuration in properties and in Acceleo launcher. | ||
+ | But, in conception, there will be the same code that display the configuration in properties and launcher. | ||
+ | |||
+ | ===== '''Launching from UML model''' ===== | ||
+ | |||
Currently, Java is generated with an Acceleo launcher | Currently, Java is generated with an Acceleo launcher | ||
[[Image:UMLGen-JavaBuilder.png|thumb|center|668px]] | [[Image:UMLGen-JavaBuilder.png|thumb|center|668px]] | ||
Line 32: | Line 55: | ||
[[Image:UMLGen-Generate AutoJava.png|thumb|center|668px]] | [[Image:UMLGen-Generate AutoJava.png|thumb|center|668px]] | ||
− | All generations can be launched in the same context menu: a menu "UML Generators". | + | |
+ | All generations can be launched in the same context menu: a menu "UML Generators". Icons on menus will be added. | ||
[[Image:UMLGen-ContextMenu.png|thumb|center|668px]] | [[Image:UMLGen-ContextMenu.png|thumb|center|668px]] | ||
− | ==== | + | |
− | C generation is directly launched in the context menu. | + | The generations use the configuration defined in properties pages (see Configuration part). |
+ | The Java generation Acceleo launcher will not be removed. Both of the launcher and the menu can be used to generate Java. | ||
+ | |||
+ | ===== '''Launching from UML elements''' ===== | ||
+ | |||
+ | C generation is directly launched in the context menu. Like Java generation, the "UML Generators" menu is added for consistency. | ||
[[Image:UMLGen-ContextMenuC-Before.png|thumb|center|668px]] | [[Image:UMLGen-ContextMenuC-Before.png|thumb|center|668px]] | ||
[[Image:UMLGen-ContextMenuC-after.png|thumb|center|668px]] | [[Image:UMLGen-ContextMenuC-after.png|thumb|center|668px]] | ||
− | |||
− | === C reverse | + | ==== Reversing processing ==== |
− | There are two menu actions to add and remove the C2UML nature from C projects. They currently are in the context menu " | + | |
− | + | ===== '''Configuration''' ===== | |
+ | |||
+ | Properties can be defined for C reverse, they are available from C project properties. Only an "UML Generators" container is added to the page. No other updates will be done. | ||
+ | [[Image:UMLGen-Properties Reverse C.png|thumb|center|668px]] | ||
+ | |||
+ | ===== '''Launching from applying a nature''' ===== | ||
+ | |||
+ | There are two menu actions to add and remove the C2UML nature from C projects. They currently are in the context menu "Configure" witch is used to convert projects in a nature. | ||
+ | However, these actions can launch the reverse so they will be moved in "UML Generators" menu, like the others actions. | ||
+ | |||
+ | Icons will be added for menus. | ||
+ | [[Image:UMLGen-ContextMenuCNature2.png|thumb|center|668px]] | ||
+ | |||
+ | === Iteration 2 === | ||
+ | |||
+ | ==== Generation processing ==== | ||
+ | |||
+ | (Enhancement of [[#Generation_processing|Iteration 1]]) | ||
+ | |||
+ | To be consistent, C generation should be launched from UML files too. | ||
+ | |||
+ | |||
+ | ===== '''Configuration''' ===== | ||
+ | |||
+ | This configuration is set on UML models. | ||
+ | |||
+ | The configuration (properties) of the C generation seems not to be used. So, the related properties page will be removed. | ||
+ | |||
+ | The use of "Uml" on the label of these pages is redundant (and already specified in the "UML Generators" category). So, the labels will be composed like that: | ||
+ | <target/source technology name> | ||
+ | i.e. | ||
+ | Java code | ||
+ | |||
+ | For Java generation, if we want to share, from a properties page, the same meta configuration (list of properties and user interface) in order to be really consistent and to make easy the maintenance, we have to be driven and constrained by the launch configuration system. | ||
+ | So, from a technical point of view, we have to be synchronized with this system because a launch configuration can not exist (be persisted) alone. | ||
+ | Consequently, a combo box should be available in the properties page to select an existing launch configuration applicable on the current UML model. If there is no launch configuration, this page will ask this system to initialize a new one. | ||
+ | The page will store only the launch configuration ID into the properties of the UML model. | ||
+ | |||
+ | [[ Image:UMLGen_configGen.png]] | ||
+ | |||
+ | |||
+ | ===== '''Launching from UML model''' ===== | ||
+ | |||
+ | From the contextual menu, the Java generation will be launched using the stored launch configuration referenced from the properties of the selected UML model. | ||
+ | |||
+ | The use of "Uml" on the label of the commands, in the contextual menu, is redundant (and already specified in the "UML Generators" category). So, the labels will be composed like that: | ||
+ | <generation action> <target/source technology name> | ||
+ | i.e. | ||
+ | Generate Java code | ||
+ | |||
+ | [[ Image:UMLGen_genCode.png]] | ||
+ | |||
+ | |||
+ | ==== Reversing processing ==== | ||
+ | |||
+ | (Enhancement of [[#Reversing_processing|Iteration 1]]) | ||
+ | |||
+ | ===== '''Configuration''' ===== | ||
+ | |||
+ | This configuration is set on Eclipse projects. | ||
+ | |||
+ | For now, just the C module uses a configuration at this level to define where data have to be reversed to, in a UML model (C reverser). | ||
+ | But, it seems that these properties are also used by the C generator to generate code from a piece of model (looking for data in a UML Package identified as containing source artifacts). | ||
+ | |||
+ | Also, note that C generation and reversing share a same stateful behavior, in particular about the input/output model which may be different from the selected one (from a generation) if the shared preference store is not updated correctly... | ||
+ | Maybe a re-architecture work would be required and really appreciated later (in an other scope) but, for now, we make with legacy. | ||
+ | |||
+ | Anyway, as this configuration is common to the C generation and reversing, the title of the properties page will be "C Generation and Reversing". | ||
+ | |||
+ | [[ Image:UMLGen_commonCConfig.png]] | ||
+ | |||
+ | |||
+ | ===== '''Launching from applying a nature''' ===== | ||
+ | |||
+ | Today, this nature is mainly used to initialize a reverse or generation and to activate a builder which listens to the changes in the source code or model to automatically update the related artifact(s). | ||
+ | |||
+ | But the synchronization code to model was removed (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=441328), so we have only one direction synchronization. | ||
+ | Besides, the objective is to be able to manually launch, on demand, a full reverse processing. Nevertheless, the current work flow is strongly driven by the life cycle of this nature and to try to make coexist these 2 ways may raise the risk to get some side effects (with the model and preference store management). | ||
+ | |||
+ | So, this constraint of adding/removing a nature will be removed from the scope and a menu will be available from the project to launch on demand a C code reversing. | ||
+ | The command will execute the same process as the add of the nature but without applying a nature (and so, without listeners). We will still saving configuration in the preference store to be "integrated" with legacy (but it will probably require to be reviewed later). | ||
+ | |||
+ | [[ Image:UMLGen_reverseCode.png]] | ||
== Backward Compatibility and Migration Paths == | == Backward Compatibility and Migration Paths == | ||
Line 58: | Line 168: | ||
=== User Interface Changes === | === User Interface Changes === | ||
− | + | * Generation actions will be contained in a "UML Generators" menu; | |
− | + | * Java generation will be launched from context menus actions; | |
− | + | * Java generation properties will be accessible from UML model properties; | |
+ | * Icons will be added in menu actions. | ||
=== Documentation Changes === | === Documentation Changes === | ||
− | + | All the user manual should integrate the user interfaces updates. | |
== Tests and Non-regression strategy == | == Tests and Non-regression strategy == |
Latest revision as of 10:16, 21 January 2015
Contents
Evolution Specification: User interface consistency improvement
Current status is DRAFT
Preamble
This is a proposal to improve the user interface consistency.
Relevant tickets:
- Bug 449080 - User interface consistency improvement
Introduction
The goal of this ticket is to make the user interface coherent for all the possible generations:
- context menus;
- generation builders;
- properties pages.
Detailed Specification
Iteration 1
Generation processing
Java and RTSJ generation are launched on UML files and C generation is launched on UML Elements (classes, packages...).
Configuration
All generations, Java, RTSJ and C, can be specialized using some properties like the generation target folder, the file headers... Currently, RTSJ and C generation use UML model properties
and Java generation defines them in the launcher.
For consistency, all generation properties will be accessible from the UML model properties (like RTSJ and C) in a "UML Generators" container.
With this properties, there is only one configuration by generation types. For example, Java generation has only one configuration per UML file.
Also, for Java generation, there is no synchronization between configuration in properties and in Acceleo launcher. But, in conception, there will be the same code that display the configuration in properties and launcher.
Launching from UML model
Currently, Java is generated with an Acceleo launcher
and RTSJ is launched with context menus
All generations can be launched in the same context menu: a menu "UML Generators". Icons on menus will be added.
The generations use the configuration defined in properties pages (see Configuration part).
The Java generation Acceleo launcher will not be removed. Both of the launcher and the menu can be used to generate Java.
Launching from UML elements
C generation is directly launched in the context menu. Like Java generation, the "UML Generators" menu is added for consistency.
Reversing processing
Configuration
Properties can be defined for C reverse, they are available from C project properties. Only an "UML Generators" container is added to the page. No other updates will be done.
Launching from applying a nature
There are two menu actions to add and remove the C2UML nature from C projects. They currently are in the context menu "Configure" witch is used to convert projects in a nature. However, these actions can launch the reverse so they will be moved in "UML Generators" menu, like the others actions.
Icons will be added for menus.
Iteration 2
Generation processing
(Enhancement of Iteration 1)
To be consistent, C generation should be launched from UML files too.
Configuration
This configuration is set on UML models.
The configuration (properties) of the C generation seems not to be used. So, the related properties page will be removed.
The use of "Uml" on the label of these pages is redundant (and already specified in the "UML Generators" category). So, the labels will be composed like that:
<target/source technology name>
i.e.
Java code
For Java generation, if we want to share, from a properties page, the same meta configuration (list of properties and user interface) in order to be really consistent and to make easy the maintenance, we have to be driven and constrained by the launch configuration system. So, from a technical point of view, we have to be synchronized with this system because a launch configuration can not exist (be persisted) alone. Consequently, a combo box should be available in the properties page to select an existing launch configuration applicable on the current UML model. If there is no launch configuration, this page will ask this system to initialize a new one. The page will store only the launch configuration ID into the properties of the UML model.
Launching from UML model
From the contextual menu, the Java generation will be launched using the stored launch configuration referenced from the properties of the selected UML model.
The use of "Uml" on the label of the commands, in the contextual menu, is redundant (and already specified in the "UML Generators" category). So, the labels will be composed like that:
<generation action> <target/source technology name>
i.e.
Generate Java code
Reversing processing
(Enhancement of Iteration 1)
Configuration
This configuration is set on Eclipse projects.
For now, just the C module uses a configuration at this level to define where data have to be reversed to, in a UML model (C reverser). But, it seems that these properties are also used by the C generator to generate code from a piece of model (looking for data in a UML Package identified as containing source artifacts).
Also, note that C generation and reversing share a same stateful behavior, in particular about the input/output model which may be different from the selected one (from a generation) if the shared preference store is not updated correctly... Maybe a re-architecture work would be required and really appreciated later (in an other scope) but, for now, we make with legacy.
Anyway, as this configuration is common to the C generation and reversing, the title of the properties page will be "C Generation and Reversing".
Launching from applying a nature
Today, this nature is mainly used to initialize a reverse or generation and to activate a builder which listens to the changes in the source code or model to automatically update the related artifact(s).
But the synchronization code to model was removed (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=441328), so we have only one direction synchronization. Besides, the objective is to be able to manually launch, on demand, a full reverse processing. Nevertheless, the current work flow is strongly driven by the life cycle of this nature and to try to make coexist these 2 ways may raise the risk to get some side effects (with the model and preference store management).
So, this constraint of adding/removing a nature will be removed from the scope and a menu will be available from the project to launch on demand a C code reversing. The command will execute the same process as the add of the nature but without applying a nature (and so, without listeners). We will still saving configuration in the preference store to be "integrated" with legacy (but it will probably require to be reviewed later).
Backward Compatibility and Migration Paths
Metamodel Changes
This evolution does not change any meta-models.
API Changes
This evolution does not change any API.
User Interface Changes
- Generation actions will be contained in a "UML Generators" menu;
- Java generation will be launched from context menus actions;
- Java generation properties will be accessible from UML model properties;
- Icons will be added in menu actions.
Documentation Changes
All the user manual should integrate the user interfaces updates.
Tests and Non-regression strategy
This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.
Implementation choices and tradeoffs
Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.