Community
Participate
Working Groups
Bug 494390 and bug 494391 ask for deletion of related elements when deleting capsules and protocols in a model. Doubtless there will be more such scenarios in time. These are classic cases of the "delete refactoring" and should be implemented as such using the refactoring wizard provided by the Eclipse LTK framework. The GMF edit-helper advice supports a lightweight form of this refactoring, the delete-dependents advice, but that is very limited in its scope: it is meant for objects that are more strongly bound to the things being deleted (e.g., notation views of delete elements, associations of member-end properties, etc.) that don't require user notification or intervention — they are obvious consequences of the user's delete intent. For Papyrus-RT, we need a pluggable delete refactoring framework in which participants can nominate elements to be deleted. The refactoring operation * is interactive: refactoring changes computed by the participants are presented as selectable changes in the wizard, just as in JDT refactorings. The user may un-check changes to tell the system not to delete those related elements, in which case they simply lose their references to the deleted object (or whatever the basic EMF-level consequence is) * is recursive: for additional elements to be deleted that are supplied by participants, nested refactorings process those to nominate further deletions. These are collected by the refactoring processor in a change tree that the user may select or not to bulk-include or -exclude refactoring changes * is scoped: the refactoring optionally covers also unloaded resources in the same project as the model in which the original object is deleted, or all resources in the workspace. The cross-reference index efficiently provides the resources referencing the model that could possibly have related objects that should be deleted, and which then are loaded in the editor for the refactoring participants to look at The delete refactoring wizard should be integrated via an edit-helper advice, on the DestroyElementRequest, that runs the processor on its participants to find refactoring changes. If any changes are found, then the wizard is shown for the user to decide which to accept (by default, all changes are selected). Otherwise, the advice has no further effect. If the scope of the refactoring is to be determined by the user, then it may require an initial pop-up dialog (with an option to "remember my decision"), or a preference, or some other affordance to stream-line the delete action. The delete refactoring participants must not overlap with delete-dependents advice for basic/required structural integrity of the model, but must only handle higher-level concerns. For example, the refactoring framework is not appropriate for deletion of views of the deleted element, deletion of an association when a member-end is deleted, etc. These cases are already handled by edit-helper advice.
I am not fully sure that the user always should be confronted with the choice of not deleting related elements and thus loosing their reference to the deleted object. Both the cases in Bug 494390 and Bug 494391 is all about avoiding the situation where ports and capsule parts are "typeless". Better then to simply present the list of related elements that will be removed, and the get the users confirmation to delete those as well. If the users does not want them deleted, then the complete delete operations is canceled, e.g. not deleting the protocol if the user don't want the related ports to be removed. This I feel is better than "fooling" the user into getting untyped ports.
(In reply to Peter Cigehn from comment #1) > I am not fully sure that the user always should be confronted with the > choice of not deleting related elements and thus loosing their reference to > the deleted object. Both the cases in Bug 494390 and Bug 494391 is all about > avoiding the situation where ports and capsule parts are "typeless". The refactoring wizard only requires the user to review the changes that it would perform if there are warnings. In the protocol and capsule deletion scenario, there needn't be any warnings, so the user should be able to finish the refactoring without reviewing the changes. And, by default, all changes proposed by refactoring participants are selected unless the user reviews and un-checks them. Does that address your concern?
(In reply to Christian W. Damus from comment #2) > (In reply to Peter Cigehn from comment #1) > > I am not fully sure that the user always should be confronted with the > > choice of not deleting related elements and thus loosing their reference to > > the deleted object. Both the cases in Bug 494390 and Bug 494391 is all about > > avoiding the situation where ports and capsule parts are "typeless". > > The refactoring wizard only requires the user to review the changes that it > would perform if there are warnings. In the protocol and capsule deletion > scenario, there needn't be any warnings, so the user should be able to > finish the refactoring without reviewing the changes. And, by default, all > changes proposed by refactoring participants are selected unless the user > reviews and un-checks them. > > Does that address your concern? Yes, that would address my concern. If the user absolutely want to keep the port/capsule part untyped, and thus have to make a deliberate choice by un-checking them, then that should be okay.
Assigned to Christian to provide an estimate of the work required.
An effort on refactoring and ltk integration in Papyrus was performed by Quentin. 'URL link' points out to this framework. This may be of use in Papyrus-RT.
(In reply to Remi Schnekenburger from comment #5) > An effort on refactoring and ltk integration in Papyrus was performed by > Quentin. 'URL link' points out to this framework. > This may be of use in Papyrus-RT. Good to know, but the link points to Oxygen functionality. Are you saying that this should wait for an Oxygen-based Papyrus-RT release, i.e., post 1.0?
(In reply to Charles Rivet from comment #6) > (In reply to Remi Schnekenburger from comment #5) > > An effort on refactoring and ltk integration in Papyrus was performed by > > Quentin. 'URL link' points out to this framework. > > This may be of use in Papyrus-RT. > > Good to know, but the link points to Oxygen functionality. Are you saying > that this should wait for an Oxygen-based Papyrus-RT release, i.e., post 1.0? yes, as the bug 478298, depending on Oxygen new developments.
(In reply to Remi Schnekenburger from comment #7) > > > > Good to know, but the link points to Oxygen functionality. Are you saying > > that this should wait for an Oxygen-based Papyrus-RT release, i.e., post 1.0? > > yes, as the bug 478298, depending on Oxygen new developments. Re-scheduling to the future.
