Community
Participate
Working Groups
Hi, While using removeLine action in a table, I found out that if I remove a line, the corresponding columns are kept even if there are no longer elements which own their estructuralFeature. Same thing for obsolete Facet column, I am wondering whether a Facet Column should be removed when it does no longer apply to any model element. In my opinion the facet should not be unloaded, so that when the user add a element the facet is applicable to, its corresponding facet column could be added again. What do you think of that ? Regards, Nicolas Guyomar
Of course, same problem occurs while using the "delete" command I think we should add an "isColumnObsolete()" (or "getObsoleteColumns()" ) method which would be called at the opening of a serialized table, as well as when we get notified of a model modification. Nicolas
(In reply to comment #0) > In my opinion the facet should not be unloaded, so that when the user add a > element the facet is applicable to, its corresponding facet column could be > added again. +1
(In reply to comment #0) I think that the facet should not be unloaded, but the unused (facet)columns should be destroyed.
Created attachment 196436 [details] Patch for Bug 346465 Hi, I have added a method in the TableInstanceCommandFactory to create a command dedicated to check whether some columns are outdated. - If a facetColumn is obsolete, then it is removed (corresponding facet is NOT unloaded) This command is appended to RemoveLine and DeleteSelectedElement's one, so that columns reappears on undo/redo There were some minors code modifications to perfom in order to prevent IndexOutOfBoundException from happening since the selectionLayer get notified while we remove columns. This scenario (delete/remove line) has to be covered by a non regression test. (a) I, Nicolas Guyomar, wrote 100% of the code I've provided. (b) I have the right to contribute the code to Eclipse. (c) I contribute the content under the EPL. (d) This contribution contains no Cryptography features. Regards, Nicolas Guyomar
Created attachment 196514 [details] Patch for Bug 346465 Non regression test Hi, Please find attached a non regression test for this scenario. (a) I, Nicolas Guyomar, wrote 100% of the code I've provided. (b) I have the right to contribute the code to Eclipse. (c) I contribute the content under the EPL. (d) This contribution contains no Cryptography features. Regards, Nicolas Guyomar
Hello, This bug is not blocking or critical. In conformance with the ramp down policy [1], the commit of its fixing will then be delayed to version 0.1.1 (Indigo SR1). [1] http://wiki.eclipse.org/Modeling_Project_Ramp_Down_Policy Regards, Gregoire Dupe
Comment on attachment 196436 [details] Patch for Bug 346465 Here is a contribution from one employee of Mia-Software, targeting future Indigo release. The company has signed a Member Commiter Agreement. The contribution does not need a CQ (see bug 322327). I've committed this contribution. Committed revision 721.
Comment on attachment 196514 [details] Patch for Bug 346465 Non regression test Here is a contribution from one employee of Mia-Software, targeting future Indigo release. The company has signed a Member Commiter Agreement. The contribution does not need a CQ (see bug 322327). I've committed this contribution. Committed revision 721.
This bug can be marked as resolved.
This bug can be closed.
