Community
Participate
Working Groups
Created attachment 288705 [details] tree.creation.tool.design.zip Nominal case: When a tool is defined to create several elements in a tree, the new elements are revealed (by expanding their parents if necessary). If the parent/child relations of the tree are not directly linked to the semantic parent/child relations, the behavior is not similar. Steps to reproduce * Import "tree.creation.tool.design" projet in your workspace * Launch a runtime * Import "tree.creation.tool.sample" projet in your runtime * Expand My.ecore and create a new "MyTree" representation on root package * Expand "p1" * Execute tool "CreateElementsWithSameSemanticRelationsUsingAQL" through contextual menu on "p12" * Expected: "p12" is expanded a new children "NewSubPacage1", "NewClass" and "newAttribute" are visible. "NewSubPacage1" is selected. --> OK * Close the new "MyTree" representation without saving * Create a new "MyTree" representation on root package * Expand "p1" * Execute tool "CreateElementsWithoutSameSemanticRelationsUsingAQL" through contextual menu on "p12" * Expected: "p12" is expanded a new children "NewSubPacage1", "NewClass" and "ClassD" are visible. "NewSubPacage1" is selected. --> KO, "NewClass" is not expanded and so "ClassD" is not visible. * You can do the same with tool "CreateElementsWithSameSemanticRelationsUsingJavaService" and "CreateElementsWithoutSameSemanticRelationsUsingJavaService". The scenario is similar. Indeed, the problem is not specific to "AQL" or java services.
Created attachment 288706 [details] tree.creation.tool.sample.zip
The selection/reveal behavior has been added through bug 428545 [1]. In this bugzilla, to maintain a lazy "loading/creation" of the tree elements, a semantic "ancestor" computation concerning new semantic elements has been added in method "willBeExpandedOnSelection(RefreshPlan)" [2]. Since 2015, the corresponding code has been refactored and the code is now in class "org.eclipse.sirius.tree.business.internal.dialect.common.tree.CreatedTreeItem": methods "synchronizeChildren(RefreshPlan)" and "willBeExpandedOnSelection(RefreshPlan)". The semantic "ancestor" computation is not relevant if the tree hierarchy is not mapped to the semantic hierarchy. As consequence, some elements are not revealed (as it is the case in above scenario). We have to find another way to maintain a lazy "loading/creation" of the tree elements and have a correct reveal behavior. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=428545 [2] https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/diff/plugins/org.eclipse.sirius.tree/src/org/eclipse/sirius/tree/business/internal/dialect/common/tree/DTreeRefresh.java?id=c22c95db074dc6f12790a0fd39ccaf2d460f13a3
These tests are probably to update or to check: * org.eclipse.sirius.tests.swtbot.tree.CreatedDTreeItemsSelectionTests * org.eclipse.sirius.tests.unit.tree.tools.SelectionInTreeAfterToolExecutionTest
Analysis summary: The refresh mechanism of the tree is "lazy". Only the visible elements are refreshed. For the not visible children of the visible elements, only a first not refreshed child is created, to have the "+" button displayed. This is only at the expand that the children are really refreshed. This has been done like this for performance reasons, even for "infinite tree" or for tree with a big depth. In 2015, new code has been added to automatically select the new tree element after a create tool execution. This code, because of the lazy mechanism, handles only some specific cases when the tree structure is "linked" to the semantic structure, in other words, more often, when the new tree elements have the new semantic elements as target. This is the more common case. So there is no simple way to handle the case explained in this issue. An approach will be to add an option in the VSM on the tree description to activate or not the lazy mode. The default mode will be lazy mode activated (as today). If the lazy mode is activated, the behavior remains the same. If the lazy mode is not activited, all possible tree items will be created on every refresh, even the ones which are not visible. This way, after a create tool execution, it will be easy to determine which elements have to be displayed (all the new tree items created). It could be possible if the complete tree is not too big. For big tree, if could be possible to have performance problem (refresh, model size, memory consumption) or maybe infinite loop (without enforcing a children computation limits). It is not is simple "problem" as it could appeared before the analysis. This improvement, as it is not a bug fix, is currently not planed in a next release. The problem is not directly linked to the usage of a reference in the semantic candidates expression. Indeed, the data has been updated to add a new case using attribute but with a tool that create the attribute in a "sub children". In this case, the tree items are neither expanded (because the code mentioned above do not handle such cases too). Another scenario: * Import "tree.creation.tool.design" projet in your workspace * Launch a runtime * Import "tree.creation.tool.sample" projet in your runtime * Expand My.ecore and create a new "MyTree" representation on root package * Expand "p1" * Execute tool "CreateAttributeOnFirstClassOfFirstPackageUsingAQL" through contextual menu on "p1" * Expected: "p11" and "ClassB" are expanded, the new child "newAttribute" is visible and selected. --> KO
Created attachment 288727 [details] tree.creation.tool.design.zip
Created attachment 288728 [details] tree.creation.tool.sample.zip
