Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » EMFT Transaction Documentation
| EMFT Transaction Documentation [message #30926] |
Wed, 12 April 2006 10:55  |
Eclipse User |
|
|
|
Originally posted by: serge.squidsolutions.com
Hello folks,
I'm investigating the promising EMF Transaction API, but I'm a little
bit cluless about the design principals behind it...
My meta-model is spread among many packages, and the resulting
data-model is also spread among many resources.
Some of my questions are:
- shall I use only one ResourceSet ?
- shall I use only one TransactionalEditingDomain ?
- how are the changes propagated from one editor to others ? magically
(!), because using the same editing domain or resourceset, or because of
the WorkspaceSynchronizer ???
So can you point me to some background documentation ?
Thanks!
Serge Fantino
www.SquidSolutions.com
|
|
|
| Re: EMFT Transaction Documentation [message #30961 is a reply to message #30926] |
Wed, 12 April 2006 13:47  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Serge,
To answer your immediate questions, I recommend using a single ResourceSet
to manage all of the Resources comprising a single EMF model. The
ResourceSet is responsible for the resolution of cross-resource references.
Using a single ResourceSet implies also a single
TransactionalEditingDomain, because an editing domain manages only one
resource set, and having multiple domains on the same resource set is
pointless and cumbersome (e.g., you would have to simultaneously open
transactions in all domains when modifying the contents of the resource
set).
Normally, editors will observe changes in by listening for Notifications.
For example, the tree-content provider adapters in your generated editor
listen for changes in their targets, to refresh the view. The
TransactionalEditingDomain gives you an additional mechanism for updating
your editors when the EMF model changes: ResourceSetChangedListener. You
can attach any number of these listeners to a TransactionalEditingDomain to
be notified of all of the changes that occurred in the editing domain
during the scope of a transaction, after the transaction has committed.
The principal benefits of this listener interface are:
- it is notified of all relevant changes in one callback, to allow
aggregate processing/analysis of the Notifications
- a post-commit listener it is only notified after the transaction
successfully commits. If it rolls back, your editor needs never think
that any changes occurred
Complete SDK documentation (programmer's guide, example guide, tutorial) is
scheduled to be committed this week for an M6a build (in addition to the
Javadocs).
Cheers,
Christian
Serge Fantino wrote:
> Hello folks,
>
> I'm investigating the promising EMF Transaction API, but I'm a little
> bit cluless about the design principals behind it...
> My meta-model is spread among many packages, and the resulting
> data-model is also spread among many resources.
> Some of my questions are:
> - shall I use only one ResourceSet ?
> - shall I use only one TransactionalEditingDomain ?
> - how are the changes propagated from one editor to others ? magically
> (!), because using the same editing domain or resourceset, or because of
> the WorkspaceSynchronizer ???
>
> So can you point me to some background documentation ?
>
> Thanks!
>
> Serge Fantino
> www.SquidSolutions.com
|
|
|
| Re: EMFT Transaction Documentation [message #30995 is a reply to message #30961] |
Wed, 12 April 2006 15:38 |
| Eclipse User |
|
|
|
Originally posted by: serge.squidsolutions.com
Thank you Christian for your quick answer!
It's good to know that the documentation is almost here :)
Regarding the ResourceSet question, if I follow your advice, I should
use only one ResourceSet for the whole application: when I open a
resource in the workbench I can't guess in advance (before loading it)
in which data-model it's part of ? And thus I should use only one
TransactionalEditingDomain for the whole application as well.
Does it sound raisonable?
Cheers,
Serge
Christian W. Damus wrote:
> Hi, Serge,
>
> To answer your immediate questions, I recommend using a single ResourceSet
> to manage all of the Resources comprising a single EMF model. The
> ResourceSet is responsible for the resolution of cross-resource references.
> Using a single ResourceSet implies also a single
> TransactionalEditingDomain, because an editing domain manages only one
> resource set, and having multiple domains on the same resource set is
> pointless and cumbersome (e.g., you would have to simultaneously open
> transactions in all domains when modifying the contents of the resource
> set).
>
> Normally, editors will observe changes in by listening for Notifications.
> For example, the tree-content provider adapters in your generated editor
> listen for changes in their targets, to refresh the view. The
> TransactionalEditingDomain gives you an additional mechanism for updating
> your editors when the EMF model changes: ResourceSetChangedListener. You
> can attach any number of these listeners to a TransactionalEditingDomain to
> be notified of all of the changes that occurred in the editing domain
> during the scope of a transaction, after the transaction has committed.
> The principal benefits of this listener interface are:
>
> - it is notified of all relevant changes in one callback, to allow
> aggregate processing/analysis of the Notifications
> - a post-commit listener it is only notified after the transaction
> successfully commits. If it rolls back, your editor needs never think
> that any changes occurred
>
> Complete SDK documentation (programmer's guide, example guide, tutorial) is
> scheduled to be committed this week for an M6a build (in addition to the
> Javadocs).
>
> Cheers,
>
> Christian
>
>
> Serge Fantino wrote:
>
>
>>Hello folks,
>>
>>I'm investigating the promising EMF Transaction API, but I'm a little
>>bit cluless about the design principals behind it...
>>My meta-model is spread among many packages, and the resulting
>>data-model is also spread among many resources.
>>Some of my questions are:
>>- shall I use only one ResourceSet ?
>>- shall I use only one TransactionalEditingDomain ?
>>- how are the changes propagated from one editor to others ? magically
>>(!), because using the same editing domain or resourceset, or because of
>>the WorkspaceSynchronizer ???
>>
>>So can you point me to some background documentation ?
>>
>>Thanks!
>>
>>Serge Fantino
>>www.SquidSolutions.com
>
>
|
|
|
| Re: EMFT Transaction Documentation [message #31172 is a reply to message #30995] |
Wed, 12 April 2006 21:58 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Serge,
If you truly don't know which model a resource belongs to, then I think this
is a reasonable approach. It is the approach adopted by the commercial
products that I work on, because our users can cross-reference their
resources arbitrarily, so any resource is potentially dependent on any
other.
Cheers,
Christian
Serge Fantino wrote:
> Thank you Christian for your quick answer!
>
> It's good to know that the documentation is almost here :)
>
> Regarding the ResourceSet question, if I follow your advice, I should
> use only one ResourceSet for the whole application: when I open a
> resource in the workbench I can't guess in advance (before loading it)
> in which data-model it's part of ? And thus I should use only one
> TransactionalEditingDomain for the whole application as well.
> Does it sound raisonable?
>
> Cheers,
> Serge
>
<snip>
|
|
|
| Re: EMFT Transaction Documentation [message #32264 is a reply to message #31172] |
Thu, 20 April 2006 18:02 |
| Eclipse User |
|
|
|
Originally posted by: none.unknown.com
Christian,
If an EditingDomain is shared by various editors, how does undo/redo work?
For instance, in editor A, you change some attribute of a model object, and
then, in editor B, you delete that model object. If you go back to editor
A, will undo be disabled (since the model object on which the resource
change happened doesn't exist anymore)? Or will undo in there undo the
delete?
Pratik
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:e1jt6p$db$1@utils.eclipse.org...
>
> Hi, Serge,
>
> If you truly don't know which model a resource belongs to, then I think
> this
> is a reasonable approach. It is the approach adopted by the commercial
> products that I work on, because our users can cross-reference their
> resources arbitrarily, so any resource is potentially dependent on any
> other.
>
> Cheers,
>
> Christian
>
> Serge Fantino wrote:
>
>> Thank you Christian for your quick answer!
>>
>> It's good to know that the documentation is almost here :)
>>
>> Regarding the ResourceSet question, if I follow your advice, I should
>> use only one ResourceSet for the whole application: when I open a
>> resource in the workbench I can't guess in advance (before loading it)
>> in which data-model it's part of ? And thus I should use only one
>> TransactionalEditingDomain for the whole application as well.
>> Does it sound raisonable?
>>
>> Cheers,
>> Serge
>>
>
> <snip>
|
|
|
| Re: EMFT Transaction Documentation [message #32510 is a reply to message #32264] |
Fri, 21 April 2006 12:03 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Pratik,
It depends on how you set up the IUndoContexts that your various editors'
Undo/Redo menus are showing.
There are two extreme cases: the undo context maps to the editing domain,
and the undo context maps to the resource.
In the first case, you would have a single undo context for the entire
editing domain so that, effectively, all of your editors are sharing a
single undo stack. In this case, your editor A will undo the deletion of
the model object. The Logic example in GMF currently demonstrates this
behaviour, although this is a bug which I think should already have a
bugzilla recorded.
In the second case, each editor's undo context is the Resource that it is
editing. The editing domain automatically appends a ResourceUndoContext to
an IUndoableOperation for every Resource that it modifies, so that if your
editor uses the ResourceUndoContext in its undo/redo menu, then editor A
will undo the deletion of the model object in this case, also. Despite the
deletion having been done in editor B, the operation will know that it
modified A's resource and will have that context also. This behaviour is
demonstrated by the EXTLibrary editor defined in the
org.eclipse.emf.workspace.examples.library.editor plug-in.
Basically, with the IUndoContext API, you can have the undo/redo menus do
whatever you like. The IOperationHistory API documentation will have more
information on that.
HTH,
Christian
Pratik Shah wrote:
> Christian,
>
> If an EditingDomain is shared by various editors, how does undo/redo work?
> For instance, in editor A, you change some attribute of a model object,
> and
> then, in editor B, you delete that model object. If you go back to editor
> A, will undo be disabled (since the model object on which the resource
> change happened doesn't exist anymore)? Or will undo in there undo the
> delete?
>
> Pratik
>
<snip>
|
|
|
| Re: EMFT Transaction Documentation [message #574260 is a reply to message #30926] |
Wed, 12 April 2006 13:47 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Serge,
To answer your immediate questions, I recommend using a single ResourceSet
to manage all of the Resources comprising a single EMF model. The
ResourceSet is responsible for the resolution of cross-resource references.
Using a single ResourceSet implies also a single
TransactionalEditingDomain, because an editing domain manages only one
resource set, and having multiple domains on the same resource set is
pointless and cumbersome (e.g., you would have to simultaneously open
transactions in all domains when modifying the contents of the resource
set).
Normally, editors will observe changes in by listening for Notifications.
For example, the tree-content provider adapters in your generated editor
listen for changes in their targets, to refresh the view. The
TransactionalEditingDomain gives you an additional mechanism for updating
your editors when the EMF model changes: ResourceSetChangedListener. You
can attach any number of these listeners to a TransactionalEditingDomain to
be notified of all of the changes that occurred in the editing domain
during the scope of a transaction, after the transaction has committed.
The principal benefits of this listener interface are:
- it is notified of all relevant changes in one callback, to allow
aggregate processing/analysis of the Notifications
- a post-commit listener it is only notified after the transaction
successfully commits. If it rolls back, your editor needs never think
that any changes occurred
Complete SDK documentation (programmer's guide, example guide, tutorial) is
scheduled to be committed this week for an M6a build (in addition to the
Javadocs).
Cheers,
Christian
Serge Fantino wrote:
> Hello folks,
>
> I'm investigating the promising EMF Transaction API, but I'm a little
> bit cluless about the design principals behind it...
> My meta-model is spread among many packages, and the resulting
> data-model is also spread among many resources.
> Some of my questions are:
> - shall I use only one ResourceSet ?
> - shall I use only one TransactionalEditingDomain ?
> - how are the changes propagated from one editor to others ? magically
> (!), because using the same editing domain or resourceset, or because of
> the WorkspaceSynchronizer ???
>
> So can you point me to some background documentation ?
>
> Thanks!
>
> Serge Fantino
> www.SquidSolutions.com
|
|
|
| Re: EMFT Transaction Documentation [message #574294 is a reply to message #30961] |
Wed, 12 April 2006 15:38 |
 Serge Fantino
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Thank you Christian for your quick answer!
It's good to know that the documentation is almost here :)
Regarding the ResourceSet question, if I follow your advice, I should
use only one ResourceSet for the whole application: when I open a
resource in the workbench I can't guess in advance (before loading it)
in which data-model it's part of ? And thus I should use only one
TransactionalEditingDomain for the whole application as well.
Does it sound raisonable?
Cheers,
Serge
Christian W. Damus wrote:
> Hi, Serge,
>
> To answer your immediate questions, I recommend using a single ResourceSet
> to manage all of the Resources comprising a single EMF model. The
> ResourceSet is responsible for the resolution of cross-resource references.
> Using a single ResourceSet implies also a single
> TransactionalEditingDomain, because an editing domain manages only one
> resource set, and having multiple domains on the same resource set is
> pointless and cumbersome (e.g., you would have to simultaneously open
> transactions in all domains when modifying the contents of the resource
> set).
>
> Normally, editors will observe changes in by listening for Notifications.
> For example, the tree-content provider adapters in your generated editor
> listen for changes in their targets, to refresh the view. The
> TransactionalEditingDomain gives you an additional mechanism for updating
> your editors when the EMF model changes: ResourceSetChangedListener. You
> can attach any number of these listeners to a TransactionalEditingDomain to
> be notified of all of the changes that occurred in the editing domain
> during the scope of a transaction, after the transaction has committed.
> The principal benefits of this listener interface are:
>
> - it is notified of all relevant changes in one callback, to allow
> aggregate processing/analysis of the Notifications
> - a post-commit listener it is only notified after the transaction
> successfully commits. If it rolls back, your editor needs never think
> that any changes occurred
>
> Complete SDK documentation (programmer's guide, example guide, tutorial) is
> scheduled to be committed this week for an M6a build (in addition to the
> Javadocs).
>
> Cheers,
>
> Christian
>
>
> Serge Fantino wrote:
>
>
>>Hello folks,
>>
>>I'm investigating the promising EMF Transaction API, but I'm a little
>>bit cluless about the design principals behind it...
>>My meta-model is spread among many packages, and the resulting
>>data-model is also spread among many resources.
>>Some of my questions are:
>>- shall I use only one ResourceSet ?
>>- shall I use only one TransactionalEditingDomain ?
>>- how are the changes propagated from one editor to others ? magically
>>(!), because using the same editing domain or resourceset, or because of
>>the WorkspaceSynchronizer ???
>>
>>So can you point me to some background documentation ?
>>
>>Thanks!
>>
>>Serge Fantino
>>www.SquidSolutions.com
>
>
|
|
|
| Re: EMFT Transaction Documentation [message #574457 is a reply to message #30995] |
Wed, 12 April 2006 21:58 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Serge,
If you truly don't know which model a resource belongs to, then I think this
is a reasonable approach. It is the approach adopted by the commercial
products that I work on, because our users can cross-reference their
resources arbitrarily, so any resource is potentially dependent on any
other.
Cheers,
Christian
Serge Fantino wrote:
> Thank you Christian for your quick answer!
>
> It's good to know that the documentation is almost here :)
>
> Regarding the ResourceSet question, if I follow your advice, I should
> use only one ResourceSet for the whole application: when I open a
> resource in the workbench I can't guess in advance (before loading it)
> in which data-model it's part of ? And thus I should use only one
> TransactionalEditingDomain for the whole application as well.
> Does it sound raisonable?
>
> Cheers,
> Serge
>
<snip>
|
|
|
| Re: EMFT Transaction Documentation [message #575735 is a reply to message #31172] |
Thu, 20 April 2006 18:02 |
Pratik Shah
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
Christian,
If an EditingDomain is shared by various editors, how does undo/redo work?
For instance, in editor A, you change some attribute of a model object, and
then, in editor B, you delete that model object. If you go back to editor
A, will undo be disabled (since the model object on which the resource
change happened doesn't exist anymore)? Or will undo in there undo the
delete?
Pratik
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:e1jt6p$db$1@utils.eclipse.org...
>
> Hi, Serge,
>
> If you truly don't know which model a resource belongs to, then I think
> this
> is a reasonable approach. It is the approach adopted by the commercial
> products that I work on, because our users can cross-reference their
> resources arbitrarily, so any resource is potentially dependent on any
> other.
>
> Cheers,
>
> Christian
>
> Serge Fantino wrote:
>
>> Thank you Christian for your quick answer!
>>
>> It's good to know that the documentation is almost here :)
>>
>> Regarding the ResourceSet question, if I follow your advice, I should
>> use only one ResourceSet for the whole application: when I open a
>> resource in the workbench I can't guess in advance (before loading it)
>> in which data-model it's part of ? And thus I should use only one
>> TransactionalEditingDomain for the whole application as well.
>> Does it sound raisonable?
>>
>> Cheers,
>> Serge
>>
>
> <snip>
|
|
|
| Re: EMFT Transaction Documentation [message #575931 is a reply to message #32264] |
Fri, 21 April 2006 12:03 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Pratik,
It depends on how you set up the IUndoContexts that your various editors'
Undo/Redo menus are showing.
There are two extreme cases: the undo context maps to the editing domain,
and the undo context maps to the resource.
In the first case, you would have a single undo context for the entire
editing domain so that, effectively, all of your editors are sharing a
single undo stack. In this case, your editor A will undo the deletion of
the model object. The Logic example in GMF currently demonstrates this
behaviour, although this is a bug which I think should already have a
bugzilla recorded.
In the second case, each editor's undo context is the Resource that it is
editing. The editing domain automatically appends a ResourceUndoContext to
an IUndoableOperation for every Resource that it modifies, so that if your
editor uses the ResourceUndoContext in its undo/redo menu, then editor A
will undo the deletion of the model object in this case, also. Despite the
deletion having been done in editor B, the operation will know that it
modified A's resource and will have that context also. This behaviour is
demonstrated by the EXTLibrary editor defined in the
org.eclipse.emf.workspace.examples.library.editor plug-in.
Basically, with the IUndoContext API, you can have the undo/redo menus do
whatever you like. The IOperationHistory API documentation will have more
information on that.
HTH,
Christian
Pratik Shah wrote:
> Christian,
>
> If an EditingDomain is shared by various editors, how does undo/redo work?
> For instance, in editor A, you change some attribute of a model object,
> and
> then, in editor B, you delete that model object. If you go back to editor
> A, will undo be disabled (since the model object on which the resource
> change happened doesn't exist anymore)? Or will undo in there undo the
> delete?
>
> Pratik
>
<snip>
|
|
|
Goto Forum:
Current Time: Sun Sep 01 03:59:08 GMT 2024
Powered by FUDForum. Page generated in 0.05389 seconds |
] 
Search
Help
Register
Login
Home
