Re: [mdt-papyrus.dev] Automatic reload of models (if underlying resource

[Ansgar Radermacher <ansgar.radermacher@xxxxxx>]

Dear all,

I have checked in a solution for the reload. It supports the reload of
the model that is edited (tool asks user if he wants to reload) and of
imports (are unloaded automatically without user intervention, will
reload the new contents on demand). In the moment, there are no
additional mechanism for preventing the user from simultaneous editing
which would be important in the context of multiple users working on the
same resource (and which would require quite different mechanisms of
opening models, probably not file-based).

1. The observation/tests seemed to indicate that the resource set does
not contains UML imports and tried to figure out how to detect imports
without writing UML specific code ... until I found out that imports are
indeed part of the resource set, but do not appear until the imports are
actually loaded (proxy resolution). Although I was in principal aware of
the "on-demand" loading policy, I thought resources would always be
created but only load on demand (resource have an "isLoaded" flag). I
added a comment to the model set to clarify this issue.

2. I had a strange behavior with regards to imports: the model explorer
updated these correctly, when I used an Eclipse text editor for the
imported model (e.g. changed a class name), but not when I changed the
name with an external editor+executed a refresh with the navigator. The
simple reason for the different behavior: In my case, the navigator and
model explorer share the same panel, i.e. only one of same is visible at
a given time: when I call refresh, the explorer is temporarly invisible.
The problem is (see bug 326851) that the model explorer does not perform
refresh operations when not visible which is an issue independ of
automatic reloads. As a quick workaround, the refreshs are always enabled.

Best regards

Ansgar

On 09/24/2010 12:10 PM, Vincent Hémery wrote:
> Hello,
>
> We have developped a feature which is very close to this in Topcased.
>
>
> There are two different approaches, but I do not know whether the
> second one is feasable :
>
> 1. Use the same one as on Topcased, with each editor using a different
>
> 2. Use a common editing domain to share the resource whithin the
> different editors. In such a case, changes made in one editor will be
> repercuted on all editors, without having to reaload anything. All
> conflict problems will be (almost magically) solved.
> The main problem is that normally, having one editing domain also
> means having only one command stack. And we would prefer keep
> separated command stacks within each editor.
>
>
>
> On Topcased, we have chosen the 1st approach. So I can give you more
> details about it :
>
> In such a context, I think your approach of tracking resources changes
> is the correct one. It is the same one as we applied on Topcased.
>
> My advice is to keep a list of resources which have been modified to
> reload them only when it is necessary.
>
> The main problematic is that giving write access to every editor will
> cause conflicts on resources.
> Hence, you will have two options :
>  A. Detect when these conflicts may occur and open only one editor in
> write mode by group of ModelSet sharing a same Model.
>   This approach allows to minimize the number of reload, which may
> cost a lot of time.
>  B. Reload at each modification as suggested in the bug. The problem
> is that if you edit with two conflicting editors, you will keep always
> refreshing the editors before each modification.
>
> In Topcased, we've chosen approach A.
>
> If you want to perform a refresh at each time the editor gets the
> focus, you can perform it with a listener with the following code on
> the editor :
> PartListenerAdapter listener;
> getSite().getPage().addPartListener(listener);
>
> Though, I think authorizing conflicting editors working on the same
> resources is a bad idea. On the other hand, you can use it to perform
> other tasks, such as a check of read-only files.
>
>
> While I'm talking about the write access of editors (hence about
> editors in read-only), I do not know either how files with the
> read-only attribute have been handled in Papyrus.
> This will most probably happen when users use files shared with SVN,
> with a lock policy making all file read-only by default.
> In such conditions, it would be a good thing if Papyrus forbides to
> edit the read-only files in the editor.
>
>
> Another point which you should be aware of : there are resource
> loading mechanisms which already exist on Papyrus. Have a look on the
> org.eclipse.papyrus.core.resourceloading plugin.
> You may have to use them or they may impose you some restrictions.
>
>
> This is a vast task you are beginning. You may contact me if you have
> other interrogations.
>
> Best regards,
> Vincent.


-- 
Ansgar Radermacher                CEA/DRT/DILS/LISE
http://www-list.cea.fr/index.htm
http://www2.cs.unibw.de/alumni/Ansgar/
phone: +33 16908 3812
mailto: ansgar.radermacher@xxxxxx