[
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)
|
Yes they are.
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Tristan FAURE
Envoyé : mardi 5 octobre 2010 11:27
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Automatic reload of models (if underlying resources change)
Thank you Sebastien,
I knew these concepts but more generally in UML implementation these elements are connected to additional resources which will be loaded from the ResourceSet (or DiModelSet in Papyrus).
Regards
Tristan
Le 05/10/2010 11:19, GERARD Sebastien 166342 a écrit :
> Hi Tristan,
>
> By UML imports, Ansgar refers to ElementImport and PackageImport of UML. These concepts are two standard concept of UML2 in order to model import in a UML model in standard way. See the spec respectively on pages 66 and 113.
>
> Best... Sébastien.
>
>
>
>
> -----Message d'origine-----
> De : mdt-papyrus.dev-bounces@xxxxxxxxxxx
> [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Tristan
> FAURE Envoyé : mardi 5 octobre 2010 11:13 À : Papyrus Project list
> Objet : 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
VERSION:2.1
X-MS-SIGNATURE:YES
N;LANGUAGE=fr;CHARSET=Windows-1252:Gérard;Sébastien;;Dr.
FN;CHARSET=Windows-1252:Dr. Sébastien Gérard
ORG:Expert Senior CEA;DRT/LIST/DILS/LISE
TEL;WORK;VOICE:+33 (0) 169085824
TEL;CELL;VOICE:+33 (0) 688200047
ADR;WORK;PREF:;;CEA Saclay DRT/LIST/DILS/LISE;GIF/YVETTE CEDEX;;91191;France
LABEL;WORK;PREF;ENCODING=QUOTED-PRINTABLE:CEA Saclay DRT/LIST/DILS/LISE=0D=0A=
91191 GIF/YVETTE CEDEX
X-MS-OL-DEFAULT-POSTAL-ADDRESS:2
EMAIL;PREF;INTERNET:Sebastien.GERARD@xxxxxx
X-MS-TEXT;CUSTOM1:If you need a UML2 tool, go to http://www.eclipse.org/papyrus
X-MS-CARDPICTURE;TYPE=JPEG;ENCODING=BASE64:
/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQY
GBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYa
KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAAR
CAAkACQDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD6nqpf39np0Pm311BbRf3ppAg/WvMvjZ8S
p/CUdvovhy3N74mvx+5iRS5iUnG7aOSTzgfjXk9l8EfHvjeb+0vGmt/ZHl+bbcs08ig9ggIV
fpkUAfQGseOdLtLNJ9Pkjv1dSyvDIPLwCQTu+oPT0rF0n4nRXJhlnslNpMQFmgl34ycDIIHf
jiq+jfC99J8OWGnDVVuHtI/KEpt/LDLkkZG48jOK47UAlpN5RZSElxuXphTkn8gf0r5rEYzG
0sZGnb3ZSSW2q/O5nUn7NOT2R77aXEN1bRXEDLJDKodHXowIyDRXk3wv8VNb+G5LackiC5dY
/ZSA2PzY0V9a8LJOxyU8fTnFS7nWeGPCMNt4l1PxPqSCbWb2QrE78/Z4BwqL6ZAyT74rs6KK
5zvOQ+IWtHTtPFtC+2acHc391O9eEazfNI7RjILAZHovXH1PBP4e9eheOpjqHiaaBssnmJDt
65XIzx+dZPhH4eajr199t16KSz05nLsr8Szd8Afwj3PPp615+TqniMXUxlfaDtFfmzxc2Ves
o0KK+Ld9kb/wo8MrP4V+13WV+1TtLH7phVB/HaT+NFeq29vFbwRwwrsijUIiKOFAGABRXsyx
Um27nTSy+EIKPYmooormPRK8dtbpOXSCJXb5iwQZJ+tWKKKiCsAUUUVYH//Z
X-MS-OL-DESIGN;CHARSET=utf-8:<card xmlns="http://schemas.microsoft.com/office/outlook/12/electronicbusinesscards"; ver="1.0" layout="left" bgcolor="ffffff"><img xmlns="" align="tleft" area="18" use="cardpicture"/><fld xmlns="" prop="name" align="left" dir="ltr" style="b" color="000000" size="10"/><fld xmlns="" prop="org" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="dept" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="email" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="telwork" align="left" dir="ltr" color="000000" size="8"><label align="right" color="626262">Bureau</label></fld><fld xmlns="" prop="telcell" align="left" dir="ltr" color="000000" size="8"><label align="right" color="626262">Mobile</label></fld><fld xmlns="" prop="addrwork" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="text1" align="left" dir="ltr" style="b" color="000000" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/></card>
REV:20100917T073951Z
END:VCARD
