| Sharing one EditingDomain and its ResourceSet [message #510194] |
Tue, 26 January 2010 11:24  |
Eclipse User |
|
|
|
I'm building an application which needs to be able to edit multiple EMF documents in different packages in multiple different ways. I started by trying to use the common navigator framework to create a project overview which used a content extension to switch to a view of the EMF document and opened an EMF.Edit instance when it was required to edit it.
After a little bit of experimentation and a lot of reading it became obvious that I was creating multiple copies of the same domain objects because I was loading the same URI at different points and this proved to be a very bad idea when it came to synchronizing viewers and state.
I've been looking at the use of EdtingDomain in the generated EMF.Edit code, it seems to me that what I really want to do is to load each URI once and then share that instance between the various editors and viewers, but the generated code creates one EditingDomain instance for each editor.
So, my question is simple. What problems will I encounter if I create one EditingDomain instance for each EMF package and share that instance between all my editors and viewers? (for a given package of course.)
I'd actually prefer to create one ResourceSet, but it seems that the EditingDomain implementations wrap the ResourceSet.
Any suggestions would be greatly appreciated.
TIA
Alan Chaney
|
|
|
| Re: Sharing one EditingDomain and its ResourceSet [message #510208 is a reply to message #510194] |
Tue, 26 January 2010 12:14  |
| Eclipse User |
|
|
|
--=-heMb7bq4uiAYSg0ngNqU
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Alan,
The EMF Transaction component may have just what you need. Its
TransactionalEditingDomains are easily shared between multiple editors
via a registry of editing domains and the integration with the Eclipse
Workbench's IOperationHistory API ensures that each editor maintains its
own Undo/Redo stack in a consistent fashion.
Have a look at the Developer Guide documentation and the transactional
editor example:
http://help.eclipse.org/galileo/topic/org.eclipse.emf.worksp ace.doc/tutorials/workspaceTutorial.html
HTH,
Christian
On Tue, 2010-01-26 at 11:25 -0500, Alan Chaney wrote:
> I'm building an application which needs to be able to edit multiple EMF documents in different packages in multiple different ways. I started by trying to use the common navigator framework to create a project overview which used a content extension to switch to a view of the EMF document and opened an EMF.Edit instance when it was required to edit it.
>
> After a little bit of experimentation and a lot of reading it became obvious that I was creating multiple copies of the same domain objects because I was loading the same URI at different points and this proved to be a very bad idea when it came to synchronizing viewers and state.
>
> I've been looking at the use of EdtingDomain in the generated EMF.Edit code, it seems to me that what I really want to do is to load each URI once and then share that instance between the various editors and viewers, but the generated code creates one EditingDomain instance for each editor.
>
> So, my question is simple. What problems will I encounter if I create one EditingDomain instance for each EMF package and share that instance between all my editors and viewers? (for a given package of course.)
>
> I'd actually prefer to create one ResourceSet, but it seems that the EditingDomain implementations wrap the ResourceSet.
>
> Any suggestions would be greatly appreciated.
>
> TIA
>
> Alan Chaney
>
--=-heMb7bq4uiAYSg0ngNqU
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Alan,<BR>
<BR>
The EMF Transaction component may have just what you need. Its TransactionalEditingDomains are easily shared between multiple editors via a registry of editing domains and the integration with the Eclipse Workbench's IOperationHistory API ensures that each editor maintains its own Undo/Redo stack in a consistent fashion.<BR>
<BR>
Have a look at the Developer Guide documentation and the transactional editor example:<BR>
<BR>
<A HREF=" http://help.eclipse.org/galileo/topic/org.eclipse.emf.worksp ace.doc/tutorials/workspaceTutorial.html"> http://help.eclipse.org/galileo/topic/org.eclipse.emf.worksp ace.doc/tutorials/workspaceTutorial.html</A><BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Tue, 2010-01-26 at 11:25 -0500, Alan Chaney wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
I'm building an application which needs to be able to edit multiple EMF documents in different packages in multiple different ways. I started by trying to use the common navigator framework to create a project overview which used a content extension to switch to a view of the EMF document and opened an EMF.Edit instance when it was required to edit it.
After a little bit of experimentation and a lot of reading it became obvious that I was creating multiple copies of the same domain objects because I was loading the same URI at different points and this proved to be a very bad idea when it came to synchronizing viewers and state.
I've been looking at the use of EdtingDomain in the generated EMF.Edit code, it seems to me that what I really want to do is to load each URI once and then share that instance between the various editors and viewers, but the generated code creates one EditingDomain instance for each editor.
So, my question is simple. What problems will I encounter if I create one EditingDomain instance for each EMF package and share that instance between all my editors and viewers? (for a given package of course.)
I'd actually prefer to create one ResourceSet, but it seems that the EditingDomain implementations wrap the ResourceSet.
Any suggestions would be greatly appreciated.
TIA
Alan Chaney
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-heMb7bq4uiAYSg0ngNqU--
|
|
|
| Re: Sharing one EditingDomain and its ResourceSet [message #510248 is a reply to message #510208] |
Tue, 26 January 2010 17:04 |
| Eclipse User |
|
|
|
Thanks Christian
I've had a play with the Transactional stuff and it seems very helpful, especially as my plans for the application would require support for multiple long-running threads and it seems that the EMF Transactions could solve a number of problems in this scenario.
Regards
Alan
|
|
|
| Re: Sharing one EditingDomain and its ResourceSet [message #510253 is a reply to message #510248] |
Tue, 26 January 2010 12:36 |
| Eclipse User |
|
|
|
--=-YUv3nQ8G5RQHpMbzt2dT
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Alan,
That sounds promising. I'm glad to hear that this might solve more
problems for you.
If you have further questions or concerns, you know where to ask!
Christian
On Tue, 2010-01-26 at 17:04 -0500, Alan Chaney wrote:
> Thanks Christian
>
> I've had a play with the Transactional stuff and it seems very helpful, especially as my plans for the application would require support for multiple long-running threads and it seems that the EMF Transactions could solve a number of problems in this scenario.
>
>
>
> Regards
>
> Alan
>
--=-YUv3nQ8G5RQHpMbzt2dT
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Alan,<BR>
<BR>
That sounds promising. I'm glad to hear that this might solve more problems for you.<BR>
<BR>
If you have further questions or concerns, you know where to ask!<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Tue, 2010-01-26 at 17:04 -0500, Alan Chaney wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Thanks Christian
I've had a play with the Transactional stuff and it seems very helpful, especially as my plans for the application would require support for multiple long-running threads and it seems that the EMF Transactions could solve a number of problems in this scenario.
Regards
Alan
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-YUv3nQ8G5RQHpMbzt2dT--
|
|
|
Powered by
FUDForum. Page generated in 0.04081 seconds
Home