| Creating multiple (transactional) editing domains on the same resourceset [message #416618] |
Fri, 08 February 2008 09:44  |
Eclipse User |
|
|
|
Originally posted by: oemer.yildiz.semanticedge.com
Hi,
the Javadoc of
TransactionalEditingDomain.Factory.createEditingDomain(Resou rceSet)
states that it would rarely be useful to do what I mentioned in the
subject. I don't see why... in my scenario I've got a shared
transactional EditingDomain managing the "global" model 'G', containing
building blocks other components/editors use in order to do meaningful
things.
Now I've got an editor for a second model. This model's elements can
reference instances of G's elements.
I don't want the editor to load G's resources into its own ResourceSet,
but to access G's elements contained in the ResourceSet owned by the
shared EditingDomain. Basically I want to avoid having the same global
objects in memory twice.
For me this doesn't seem to look like a rare case. Any comments on that,
what do you think?
Cheers
Ömer
|
|
|
| Re: Creating multiple (transactional) editing domains on the same resourceset [message #416626 is a reply to message #416618] |
Fri, 08 February 2008 14:11  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ömer,
I'm not entirely sure that I understand the structure of your resource sets.
You have one resource set that contains a shared resource G.
Other resource sets contain resources that make reference to G.
Every resource set has its own editing domain. I don't see where you have
multiple editing domains on one resource set.
In any given editor, operations that change the editor's resource and G will
have to open transactions in both the editor's and G's editing domain.
That is awkward, but necessary. If an editor's resource set had two or
more editing domains managing it, then *any* change in the editor's
resource set would require simultaneous transactions in all editing
domains. Moreover, each editing domain will be recording the same changes,
and undo/redo will be hard to manage. Not to mention that validation and
rollback would occur all editing domains, resulting in an unpredictable
state when all of them finish rolling back (or, probably, failure in N-1 of
them to correctly apply their change descriptions).
In fact, it would seem that the Javadoc is not strong enough in its
statement. Not only would this rarely be useful, but it just wouldn't
work :-)
I would suggest considering sharing the same resource set and editing domain
amongst all of your editors and G, using the org.eclipse.emf.workspace
plug-in's editing domain implementation and its IOperationHistory support
to keep the undo/redo menus of your editors distinct. Have a look at
the "EMF Workspace Integration" example plug-in, which demonstrates how
this all works, using a variation on EMF's extended library model editor.
HTH,
Christian
Ömer Yildiz wrote:
> Hi,
>
> the Javadoc of
> TransactionalEditingDomain.Factory.createEditingDomain(Resou rceSet)
> states that it would rarely be useful to do what I mentioned in the
> subject. I don't see why... in my scenario I've got a shared
> transactional EditingDomain managing the "global" model 'G', containing
> building blocks other components/editors use in order to do meaningful
> things.
> Now I've got an editor for a second model. This model's elements can
> reference instances of G's elements.
> I don't want the editor to load G's resources into its own ResourceSet,
> but to access G's elements contained in the ResourceSet owned by the
> shared EditingDomain. Basically I want to avoid having the same global
> objects in memory twice.
>
> For me this doesn't seem to look like a rare case. Any comments on that,
> what do you think?
>
> Cheers
> Ömer
|
|
|
Powered by
FUDForum. Page generated in 0.03124 seconds
] 
Search
Help
Register
Login
Home
