Home » Modeling » EMF » TransactionalEditingDomain in EMF generated editors
|
| Re: TransactionalEditingDomain in EMF generated editors [message #414760 is a reply to message #414759] |
Tue, 20 November 2007 20:06   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Hans,
Replacing your editing domain and command stack with their transactional
counterparts is not the whole story but, as you have discovered, the
example editor does more than the bare minimum to demonstrate other
capabilities of the API. Also, it isn't very clear what all of the
customizations in that editor are, as we haven't been able to keep it
up-to-date with changes in the codegen templates.
There are some other considerations, including at least
- replacing the property sheet and its property sources with the
transactional variants from the org.eclipse.emf.transaction.ui
plug-in
- replacing the tree content provider with its transactional variant
from the org.eclipse.emf.transaction.ui plug-in
- (for operation history integration) replacing the the Undo and Redo
actions created by the generated action-bar contributor with the
actions in the org.eclipse.emf.workspace.ui plug-in
The handling of the content and property sheet providers is important for
ensuring that refreshes use the transactional editing domain for read-only
transactions.
The example also tries to simplify the editor by removing all pages but the
default tree view.
So, you might start by progressively replacing the various pieces listed
above and see where that takes you.
On the other hand, if all that you are looking for is to be able to use
RecordingCommand, then perhaps you don't need transactions at all and the
ChangeCommand will work for you? (it similarly uses the ChangeRecorder for
automatic undo/redo)
HTH,
Christian
Hans Boerstra wrote:
> After reading the Workspace Integration example and some posts about use
> of the TransactionalEditingDomain, I am still a little unsure about the
> simples way to use a TransactionalEditingDomain in generated EMF editors.
> Is it indeed as simple as replacing
> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
> commandStack, new HashMap<Resource, Boolean>());
> with the construction of a TransactionalEditingDomain in the
> initializeEditingDomain method?
>
> As I understand it the Workspace Integration example adds support for
> multiple editors on the same resource which is not (yet) what I am after.
> I need to use the RecordingCommand and for that I need the right
> EditingDomain so my naive solution would be to just replace the
> editingDomain construction.
> Would that work out right?
>
> Regards,
>
> Hans
|
|
|
| Re: TransactionalEditingDomain in EMF generated editors [message #414763 is a reply to message #414760] |
Tue, 20 November 2007 22:07 |
 Hans Boerstra
Messages: 48
Registered: July 2009 |
Member |
|
|
Thx for the quick and thorough reply, Christian.
I think I will do both (start from the example and also try out the
ChangeCommand) to learn the most.
Maybe a good idea to create a genmodel switch to generate a Transactional
version of the EMF editors?
Regards,
Hans
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fhveom$ld7$1@build.eclipse.org...
> Hi, Hans,
>
> Replacing your editing domain and command stack with their transactional
> counterparts is not the whole story but, as you have discovered, the
> example editor does more than the bare minimum to demonstrate other
> capabilities of the API. Also, it isn't very clear what all of the
> customizations in that editor are, as we haven't been able to keep it
> up-to-date with changes in the codegen templates.
>
> There are some other considerations, including at least
> - replacing the property sheet and its property sources with the
> transactional variants from the org.eclipse.emf.transaction.ui
> plug-in
> - replacing the tree content provider with its transactional variant
> from the org.eclipse.emf.transaction.ui plug-in
> - (for operation history integration) replacing the the Undo and Redo
> actions created by the generated action-bar contributor with the
> actions in the org.eclipse.emf.workspace.ui plug-in
>
> The handling of the content and property sheet providers is important for
> ensuring that refreshes use the transactional editing domain for read-only
> transactions.
>
> The example also tries to simplify the editor by removing all pages but
> the
> default tree view.
>
> So, you might start by progressively replacing the various pieces listed
> above and see where that takes you.
>
> On the other hand, if all that you are looking for is to be able to use
> RecordingCommand, then perhaps you don't need transactions at all and the
> ChangeCommand will work for you? (it similarly uses the ChangeRecorder for
> automatic undo/redo)
>
> HTH,
>
> Christian
>
>
> Hans Boerstra wrote:
>
>> After reading the Workspace Integration example and some posts about use
>> of the TransactionalEditingDomain, I am still a little unsure about the
>> simples way to use a TransactionalEditingDomain in generated EMF editors.
>> Is it indeed as simple as replacing
>> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
>> commandStack, new HashMap<Resource, Boolean>());
>> with the construction of a TransactionalEditingDomain in the
>> initializeEditingDomain method?
>>
>> As I understand it the Workspace Integration example adds support for
>> multiple editors on the same resource which is not (yet) what I am after.
>> I need to use the RecordingCommand and for that I need the right
>> EditingDomain so my naive solution would be to just replace the
>> editingDomain construction.
>> Would that work out right?
>>
>> Regards,
>>
>> Hans
>
|
|
|
| Re: TransactionalEditingDomain in EMF generated editors [message #414765 is a reply to message #414763] |
Tue, 20 November 2007 22:53 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010103000602090500020505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hans,
Open a bugzilla to ask for the generator property. It's not so likely
we'll get to it any time soon without a contribution but at least we can
record the desire to have it.
Hans Boerstra wrote:
> Thx for the quick and thorough reply, Christian.
>
> I think I will do both (start from the example and also try out the
> ChangeCommand) to learn the most.
> Maybe a good idea to create a genmodel switch to generate a Transactional
> version of the EMF editors?
>
> Regards,
>
> Hans
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fhveom$ld7$1@build.eclipse.org...
>
>> Hi, Hans,
>>
>> Replacing your editing domain and command stack with their transactional
>> counterparts is not the whole story but, as you have discovered, the
>> example editor does more than the bare minimum to demonstrate other
>> capabilities of the API. Also, it isn't very clear what all of the
>> customizations in that editor are, as we haven't been able to keep it
>> up-to-date with changes in the codegen templates.
>>
>> There are some other considerations, including at least
>> - replacing the property sheet and its property sources with the
>> transactional variants from the org.eclipse.emf.transaction.ui
>> plug-in
>> - replacing the tree content provider with its transactional variant
>> from the org.eclipse.emf.transaction.ui plug-in
>> - (for operation history integration) replacing the the Undo and Redo
>> actions created by the generated action-bar contributor with the
>> actions in the org.eclipse.emf.workspace.ui plug-in
>>
>> The handling of the content and property sheet providers is important for
>> ensuring that refreshes use the transactional editing domain for read-only
>> transactions.
>>
>> The example also tries to simplify the editor by removing all pages but
>> the
>> default tree view.
>>
>> So, you might start by progressively replacing the various pieces listed
>> above and see where that takes you.
>>
>> On the other hand, if all that you are looking for is to be able to use
>> RecordingCommand, then perhaps you don't need transactions at all and the
>> ChangeCommand will work for you? (it similarly uses the ChangeRecorder for
>> automatic undo/redo)
>>
>> HTH,
>>
>> Christian
>>
>>
>> Hans Boerstra wrote:
>>
>>
>>> After reading the Workspace Integration example and some posts about use
>>> of the TransactionalEditingDomain, I am still a little unsure about the
>>> simples way to use a TransactionalEditingDomain in generated EMF editors.
>>> Is it indeed as simple as replacing
>>> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
>>> commandStack, new HashMap<Resource, Boolean>());
>>> with the construction of a TransactionalEditingDomain in the
>>> initializeEditingDomain method?
>>>
>>> As I understand it the Workspace Integration example adds support for
>>> multiple editors on the same resource which is not (yet) what I am after.
>>> I need to use the RecordingCommand and for that I need the right
>>> EditingDomain so my naive solution would be to just replace the
>>> editingDomain construction.
>>> Would that work out right?
>>>
>>> Regards,
>>>
>>> Hans
>>>
>
>
>
--------------010103000602090500020505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hans,<br>
<br>
Open a bugzilla to ask for the generator property. It's not so likely
we'll get to it any time soon without a contribution but at least we
can record the desire to have it.<br>
<br>
<br>
Hans Boerstra wrote:
<blockquote cite="mid:fhvlrl$f0g$1@build.eclipse.org" type="cite">
<pre wrap="">Thx for the quick and thorough reply, Christian.
I think I will do both (start from the example and also try out the
ChangeCommand) to learn the most.
Maybe a good idea to create a genmodel switch to generate a Transactional
version of the EMF editors?
Regards,
Hans
"Christian W. Damus" <a class="moz-txt-link-rfc2396E" href="mailto:cdamus@ca.ibm.com"><cdamus@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:fhveom$ld7$1@build.eclipse.org">news:fhveom$ld7$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi, Hans,
Replacing your editing domain and command stack with their transactional
counterparts is not the whole story but, as you have discovered, the
example editor does more than the bare minimum to demonstrate other
capabilities of the API. Also, it isn't very clear what all of the
customizations in that editor are, as we haven't been able to keep it
up-to-date with changes in the codegen templates.
There are some other considerations, including at least
- replacing the property sheet and its property sources with the
transactional variants from the org.eclipse.emf.transaction.ui
plug-in
- replacing the tree content provider with its transactional variant
from the org.eclipse.emf.transaction.ui plug-in
- (for operation history integration) replacing the the Undo and Redo
actions created by the generated action-bar contributor with the
actions in the org.eclipse.emf.workspace.ui plug-in
The handling of the content and property sheet providers is important for
ensuring that refreshes use the transactional editing domain for read-only
transactions.
The example also tries to simplify the editor by removing all pages but
the
default tree view.
So, you might start by progressively replacing the various pieces listed
above and see where that takes you.
On the other hand, if all that you are looking for is to be able to use
RecordingCommand, then perhaps you don't need transactions at all and the
ChangeCommand will work for you? (it similarly uses the ChangeRecorder for
automatic undo/redo)
HTH,
Christian
Hans Boerstra wrote:
</pre>
<blockquote type="cite">
<pre wrap="">After reading the Workspace Integration example and some posts about use
of the TransactionalEditingDomain, I am still a little unsure about the
simples way to use a TransactionalEditingDomain in generated EMF editors.
Is it indeed as simple as replacing
editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
commandStack, new HashMap<Resource, Boolean>());
with the construction of a TransactionalEditingDomain in the
initializeEditingDomain method?
As I understand it the Workspace Integration example adds support for
multiple editors on the same resource which is not (yet) what I am after.
I need to use the RecordingCommand and for that I need the right
EditingDomain so my naive solution would be to just replace the
editingDomain construction.
Would that work out right?
Regards,
Hans
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------010103000602090500020505--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: TransactionalEditingDomain in EMF generated editors [message #415108 is a reply to message #414765] |
Thu, 29 November 2007 22:55 |
Hans Boerstra
Messages: 48
Registered: July 2009 |
Member |
|
|
Just added the enhancement request as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=211524
Regards,
Hans
=====================================
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fhvoh5$r3k$2@build.eclipse.org...
Hans,
Open a bugzilla to ask for the generator property. It's not so likely we'll
get to it any time soon without a contribution but at least we can record
the desire to have it.
Hans Boerstra wrote:
Thx for the quick and thorough reply, Christian.
I think I will do both (start from the example and also try out the
ChangeCommand) to learn the most.
Maybe a good idea to create a genmodel switch to generate a Transactional
version of the EMF editors?
Regards,
Hans
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fhveom$ld7$1@build.eclipse.org...
Hi, Hans,
Replacing your editing domain and command stack with their transactional
counterparts is not the whole story but, as you have discovered, the
example editor does more than the bare minimum to demonstrate other
capabilities of the API. Also, it isn't very clear what all of the
customizations in that editor are, as we haven't been able to keep it
up-to-date with changes in the codegen templates.
There are some other considerations, including at least
- replacing the property sheet and its property sources with the
transactional variants from the org.eclipse.emf.transaction.ui
plug-in
- replacing the tree content provider with its transactional variant
from the org.eclipse.emf.transaction.ui plug-in
- (for operation history integration) replacing the the Undo and Redo
actions created by the generated action-bar contributor with the
actions in the org.eclipse.emf.workspace.ui plug-in
The handling of the content and property sheet providers is important for
ensuring that refreshes use the transactional editing domain for read-only
transactions.
The example also tries to simplify the editor by removing all pages but
the
default tree view.
So, you might start by progressively replacing the various pieces listed
above and see where that takes you.
On the other hand, if all that you are looking for is to be able to use
RecordingCommand, then perhaps you don't need transactions at all and the
ChangeCommand will work for you? (it similarly uses the ChangeRecorder for
automatic undo/redo)
HTH,
Christian
Hans Boerstra wrote:
After reading the Workspace Integration example and some posts about use
of the TransactionalEditingDomain, I am still a little unsure about the
simples way to use a TransactionalEditingDomain in generated EMF editors.
Is it indeed as simple as replacing
editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
commandStack, new HashMap<Resource, Boolean>());
with the construction of a TransactionalEditingDomain in the
initializeEditingDomain method?
As I understand it the Workspace Integration example adds support for
multiple editors on the same resource which is not (yet) what I am after.
I need to use the RecordingCommand and for that I need the right
EditingDomain so my naive solution would be to just replace the
editingDomain construction.
Would that work out right?
Regards,
Hans
|
|
|
Goto Forum:
Current Time: Sat Apr 27 05:19:08 GMT 2024
Powered by FUDForum. Page generated in 0.04298 seconds |
] 
Search
Help
Register
Login
Home
