Hello,
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.
It
might be a bit early but I just wanted to remark that we
have implemented exactly this behavior in the Sphinx Workspace
Management component. We share the same editing domain across
multiple editors and views AND have found a way to include only
those operations in the undo/redo menus which are have been done in
the respective editor/view instance (by using EMF Transaction and
its integration with Eclipse Operation History).
We are currently in the provisioning process of Sphinx and look
forward to getting the code in during October. No idea what kind of
timeline constraints you have with this but it could potentially be
a starting point for getting Papyrus and Sphinx closer together.
Regards,
Stephan
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
|
