Hi Christian,
Le 07/08/2015 12:44, Christian W. Damus a écrit :
Hi, Gabriel,
It seems to me that it would never be expected that a
ProfileApplication element should be referenced by any other
model element, except perhaps a Comment. But non-UML content
such as diagram notation and tables could certainly be expected
to reference ProfileApplications, so it would be appropriate to
invoke the refactoring mechanism "under the hood" to handle
updates that the externalization function doesn't already cover.
Can the refactoring show its UI only in the case that it finds
references that need to be updated?
I recently added two ways to configure the Refactoring service
either by UI or by preferences. The first purpose was to not freeze
unit tests with an opened dialog. When the parameters come from
preferences, there are no dialog pending validation of user.
Now that I mention it, I think we probably have a bug in the
ProfileApplication externalization that it doesn't also
externalize Comments annotating the ProfileApplication that
aren't owned by it. But then, those comments could also
annotate other elements also, so it's not necessarily simple.
The LifeCycleEventsProvider's very purpose is to broadcast
events for lifecycle transitions in the editor. Why shouldn't
it require that editor? What seems odd to me is that it also
provides an API food unloading resources. That doesn't strike
me as a responsibility of an "event provider". I think it may
be best to revise how resources are unloaded by the refactoring
service.
It seemed me a good way to unload impacted resources only during
save action but I could take the problem in the other way. I could
save only the external impacted resources before to unload their at
the end of Refactoring service execution.
I will try to rework on the refactoring service to detach it of the
LifeCycleEventProvider.
HTH,
Christian
Thanks for answers and ideas !
Gabriel
On Fri, Aug 7, 2015 at 5:43 AM, Gabriel Pascual <gabriel.pascual@xxxxxxxxxxx>
wrote:
Hi,
I am working on a Refactoring mechanism[1] to avoid to break
cross-references between several projects in workspace
during an action which implies a URI change.
The task begins to take form but I have some questions:
- When I externalize the Profile Application of a
model, the Refactoring service is triggered. I would
like to know if this seems a good behaviour or the
mechanism needs to exclude it for this use case (or
others if you have suggestions) ?
- Today, the mechanism uses LifeCycleEventsProvider
service to unload external resources. This service
depends of MultiDiagramEditor service and this is
blocking because I would allow the use of Refactoring
service to outside of Editor context like with Project
Explorer action. Are there good reasons for
LifeCycleEventsProvider service is dependent of Editor ?
Regards
Gabriel
1:
https://wiki.eclipse.org/Papyrus/Neon_Work_Description/NewFeature/Papyrus_Refactoring_Service
--
|
Gabriel PASCUAL
Software Engineer
|
6 rue Léonard De Vinci - BP 0119 -
53001 LAVAL Cedex - FRANCE
www.all4tec.net
|
|
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
--
|
Gabriel
PASCUAL
Software
Engineer
|
|
Phone : +33 (0)2 44 47 23 23
Mail : gap@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL
Cedex - FRANCE
www.all4tec.net
|
|
|