[
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)
|
Dear Vincent, Dear Cedric,
thank you for your comments. I currently have something that starts to
do something useful:
The ResourceChangeListener detects, if a resource of an editor has been
changed and can reload it (unload/load on Papyrus modelSet). But the
detection is not very efficient since I do it with a listener on
workspace level and have to filter events that relate to an opened
model. In particular, this listener gets a resource change event, if the
active editor performs a save. The listener should detect this case and
not propose a subsequent reload.
But it does not need to check for a reload each time, the focus changes.
I general, I want to make a small modification, e.g. I don't want to
change how Papyrus handles editing domains.
In my opinion, the behavior should be:
(1) Offer a reload, if the resource of the "main" model (not the
resource of one of the imports) has changed. In principal, there are two
sub-cases
(a) no changes have yet been made in the editor, i.e. reload does no
harm
(b) changes have been made in the editor. These would be lost by a
reload. If no reload is done, a subsequent save might destroy other
changes. Ideally, changes are merged in but that is a quite difficult
task. The alternative is (as Vincent pointed out) to avoid this
situation by preventing two editors from working on the same file (in
write mode). Changes could not only be done by editors. In my use case,
a model transformation produces a new .uml file and I use Papyrus mainly
as a viewer for this file. Thus, it would fine, to open a model
explicitly in read-only mode or (in a premier step) to open models
always normally and live with the potential problem of conflicting changes.
(2) the resource of one of the import has changes. These should be
updated and do not destroy any changes. [btw. it is currently possible
to make changes in an imported model, but these are (of course) not
saved. Papyrus should not allow these changes - I will post a bug on
this one].
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.
>
> Le 23/09/2010 11:58, Cedric Dumoulin a écrit :
>>
>> Hi,
>>
>> I suppose that what is described in the article can be applied to
>> Papyrus.
>>
>> The Resource management is actually a work in progress:
>> In Papyrus, we try to hide the resources manipulation in a more abstract
>> level : Model and ModelSet.
>>
>> * A ModelSet is a set of Models
>> * ModelSet is a papyrus Service that can be retrieved as Service
>> * A Model is a model that can be required by Papyrus (i.e.: UML,
>> notation, sash, history, ...). A piece of code can ask the
>> ModelSet for a particular Model
>> * A Model can be spraid in several Resources, or a Resource can
>> contains several models (ex: .di contains sash and history).
>> * New Models can be registered to the ModelSet by using the Eclipse
>> extension mechanism
>>
>> Actually, the ModelSet API need to be improved, and some stuff
>> manipulating directly the Resources need to be moved in Models (like
>> stuff done in Papyrus creation wizard).
>> You can certainly implements your code in a Snippet (piece of code that
>> can be attached to a ModelSet or Model).
>>
>> Hope this help,
>> Cedric
>>
>> Ansgar Radermacher wrote:
>>> Dear all,
>>>
>>> i'd like to work on bug 313988, unless someone already started this
>>> activity.
>>>
>>> Btw: I plan to track resource changes as described in
>>> http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/resAdv_events.htm
>>>
>>> but, I have not really worked on resource manipulation yet. Is there
>>> anything (specific to Papyrus resources) that I should take into
>>> account?
>>>
>>> Best regards
>>>
>>> Ansgar
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> mdt-papyrus.dev mailing list
>> mdt-papyrus.dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
>
--
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
