| Refactoring of EMF resources on renaming/moving corresponding IFile [message #77875] |
Wed, 15 November 2006 09:58  |
Eclipse User |
|
|
|
Hello!
Not sure where to ask this question, so I’ll ask it in GMF newsgroup.
While implementing “refresh diagram content” feature for generated diagrams
I came to the following question: who is responsible for modifying EMF resource(s)
contents on moving/renaming corresponding eclipse IResources? For example:
if some model elements are stored inside resource R1, referenced from the
resource R2 content and resource R1 was moved/renamed then contents of the
resource R2 should be changed in accordance to keep it valid.
Looks like this functionality was not implemented as a part of EMF to let
the customers of EMF decide whenever they should perform such kind of refactorings
on any changes in the workspace or not. In the same time current implementation
of WorkspaceSynchronizer (part of EMFT project, was designed AFAIU to keep
ResourceSet in synch with workspace resources) rely on the fact that all
the resources currently loaded into the ResourceSet will be updated externally
– default implementation (DefaultDelegate) just unload/load corresponding
resources without any changes. Moreover, it is not possible to implement
such an updating functionality based on the current state of WorkspaceSynchronizer
for the complex changes in a resources subsystem - moved + changed resource
in the same resource delta.
Currently I’ve placed corresponding piece of code into the generated GMF
???DocumentProvider class (and not using WorkspaceSynchronizer from there
due to mentioned limitations) but will be happy to extract corresponding
code to the separate subsystem and start using WorkspaceSynchronizer in generated
code.
My questions are:
Does anybody know the correct solution for this use-case? Should each client
of EMF perform this updating process for loaded resources or should it be
performed in some central place?
Should WorkspaceSynchronizer be used for handling such a situations and modified
in appropriate way or not - if resource contents updating will be performed
externally?
-----------------
Alex Shatalin
|
|
|
| Re: Refactoring of EMF resources on renaming/moving corresponding IFile [message #77909 is a reply to message #77875] |
Wed, 15 November 2006 11:45  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Alex,
The WorkspaceSynchronizer was not intended to actually make any changes to
Resources in the ResourceSet on events from the Workspace, because it would
always be too late. Its purpose is simply to notify an application A that
some other application B has made changes resources on which A depends.
When A is the one changing the Workspace, then it is assumed that it will
not need the synchronizer to tell it about those changes.
I think what you are looking for is a Refactoring Participant, that would
proactively update dependent resources *before* any changes are saved to
Workspace files. There are two considerations:
- currently loaded resources (GMF's CrossReferenceAdapter has an exports
query that kind easily find these)
- currently unloaded resources
A refactoring partipant (or some API that a client application's participant
would use) implementing one or both of these scenarii would probably be a
valuable contribution either to GMF or to EMFT Workspace.
Cheers,
Christian
Alex Shatalin wrote:
> Hello!
>
> Not sure where to ask this question, so I’ll ask it in GMF newsgroup.
>
> While implementing “refresh diagram content” feature for generated
> diagrams I came to the following question: who is responsible for
> modifying EMF resource(s) contents on moving/renaming corresponding
> eclipse IResources? For example: if some model elements are stored inside
> resource R1, referenced from the resource R2 content and resource R1 was
> moved/renamed then contents of the resource R2 should be changed in
> accordance to keep it valid.
>
> Looks like this functionality was not implemented as a part of EMF to let
> the customers of EMF decide whenever they should perform such kind of
> refactorings on any changes in the workspace or not. In the same time
> current implementation of WorkspaceSynchronizer (part of EMFT project, was
> designed AFAIU to keep ResourceSet in synch with workspace resources) rely
> on the fact that all the resources currently loaded into the ResourceSet
> will be updated externally – default implementation (DefaultDelegate) just
> unload/load corresponding resources without any changes. Moreover, it is
> not possible to implement such an updating functionality based on the
> current state of WorkspaceSynchronizer for the complex changes in a
> resources subsystem - moved + changed resource in the same resource delta.
>
> Currently I’ve placed corresponding piece of code into the generated GMF
> ???DocumentProvider class (and not using WorkspaceSynchronizer from there
> due to mentioned limitations) but will be happy to extract corresponding
> code to the separate subsystem and start using WorkspaceSynchronizer in
> generated code.
>
> My questions are:
>
> Does anybody know the correct solution for this use-case? Should each
> client of EMF perform this updating process for loaded resources or should
> it be performed in some central place?
>
> Should WorkspaceSynchronizer be used for handling such a situations and
> modified in appropriate way or not - if resource contents updating will be
> performed externally?
>
> -----------------
> Alex Shatalin
|
|
|
|
| Re: Refactoring of EMF resources on renaming/moving corresponding IFile [message #77972 is a reply to message #77940] |
Wed, 15 November 2006 13:00 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Alex,
If you mean, does EMFT or GMF Run-time already have some API supporting
refactoring, then the answer is in the first case "no" and in the second
case "I don't think so; except for the the CrossReferenceAdapter that I
mentioned before."
A long-winded way to say that I think you're right ;-)
Cheers,
Christian
Alex Shatalin wrote:
> Hello Christian,
>
> Thank you for the clarifications. No I can understand the contracts.
>
>> A refactoring partipant (or some API that a client application's
>> participant would use) implementing one or both of these scenarii
>> would probably be a valuable contribution either to GMF or to EMFT
>> Workspace.
> Am I right that corresponding API does not exists yet or can you point me
> to the entry point to plug into it?
>
> -----------------
> Alex Shatalin
|
|
|
Powered by
FUDForum. Page generated in 0.06753 seconds
Home