[
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)
|
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
--
* Hémery Vincent*
*Ingénieur - Atos Origin*
Telephone : +33 (0) 5 34 36 32 90
www.atosorigin.fr <http://www.atosorigin.fr>
Développement durable, anticipons pour notre avenir / Sustainability,
advance our future
P N'imprimez ce mail que si nécessaire / please consider your
environmental responsibility before printing this e-mail.
Ce message et les pièces jointes sont confidentiels et réservés à
l'usage exclusif de ses destinataires. Il peut également être protégé
par le secret professionnel. Si vous recevez ce message par erreur,
merci d'en avertir immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être assurée sur Internet, la
responsabilité du groupe Atos Origin ne pourra être recherchée quant au
contenu de ce message. Bien que les meilleurs efforts soient faits pour
maintenir cette transmission exempte de tout virus, l'expéditeur ne
donne aucune garantie à cet égard et sa responsabilité ne saurait être
recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive this
e-mail in error, please notify the sender immediately and destroy it. As
its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender
does not warrant that this transmission is virus-free and will not be
liable for any damages resulting from any virus transmitted.
