[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-papyrus.dev] Automatic reload of models (if underlying resources change)
|
Hi ansgar some remarks for the 1)
Le 04/10/2010 10:11, Ansgar Radermacher a écrit :
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.
I don't understand what you mean by UML Imports ? I reckon UML Imports
are all the resources loaded by the resources except the first one.
Did you check the code of OnDemandLoadingModelSet which is in charge to
load resources according to user defined strategy ?
If you see the code you can remark that we have currently in Papyrus the
control of Resource Loading and you extend the behavior to manage which
resources are loaded or not ?
Concerning the isLoaded flag if i remember it is used if the resource
has been loaded using Tracking_modification parameter.
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.
Regards
Tristan FAURE
begin:vcard
fn:Tristan FAURE
n:FAURE;Tristan
org:Atos Origin Integration
adr;dom:BP 43045;;6 impasse alice guy;Toulouse Cedex 03;;31024
email;internet:tristan.faure@xxxxxxxxxxxxxx
title;quoted-printable:Ing=C3=A9nieur Logiciel
tel;work:05 34 36 34 46
tel;fax:05 34 36 31 00
version:2.1
end:vcard
