Home » Modeling » GMF (Graphical Modeling Framework) » SHared EditingDomain
| SHared EditingDomain [message #514211] |
Fri, 12 February 2010 20:31  |
 Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Hi all,
i tried to realize the integration of GMF and EMF editors as described
here
http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
and in Richard's book. But both documents integrate the diagram editor
into the EMF-generated editor. That's not what i want for my model. I'd
like to have several diagrams (already implement) using the same
TransactionEditingDomain as well as the EMF-generated editor.
My first question is, is this possible or does sharing an editing domain
implies sharing the editor itself.
What i actually want to realize is to implement a context menu command,
that is enabled for particular nodes. By executing such a command, a
wizard should be open and provide the possibility to configure some
internal stuff of the select node (respectively the underlying domain
model element). Since these internal stuff is not part of the GMF
diagram, i think i must retrieve the editing domain from the
EMF-generated editor and execute all changes/modifications the user
perform via its command stack. But how do i get the editing domain of
the underlying model editor?! That's why i tried to create a single
TransactionalEditingDomain for all diagrams and the EMF-generated editor...
All eclipse ui stuuf (wizards, commands, etc.) is not a problem for me,
but i have only minor experiences with GMF and EMF editing domains and
no one with the EMF transaction framework in particular. I would
appreciate it, if someone may verify or falsify my thoughts.
Thanks a lot in advance
Timothy
|
|
|
| Re: SHared EditingDomain [message #514282 is a reply to message #514211] |
Sat, 13 February 2010 15:32  |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi, here is what I recommend. (It took me some time to understand this
well, so I might as well write it down).
Option 1: Do it yourself by hand.
1. Make sure EMF' uses a Transactional Editing Domain.
2. Let the GMF Document provider also use the same editing domain.
3. Make sure the GMF Editor also use the semantic resource from the EMF
editor. (Likely what you want).
4. GMF also uses a ResourceSetInfo, which needs to be carefully
considered when Sharing an Editing domain.
One thing to remember, is that the editing domain is there for the
lifetime of the app. So, if you create resources from this domain's
resourceset, you will need to make sure which ones are loaded/unloaded.
(Check the dispose methods, for the EMF/GMF editors to see what happens
to the resources).
Option 2: Use GMFTools for item 2 above, which will require a bit more
setup, as GMFTools, actually makes modifications in the templates to
generate the code:
See: http://code.google.com/p/gmftools/wiki/SharedEditingDomain
Option 1:
>>>>1
Strip from the EMF Editor, the creation of an EditingDomain.
Create an editing domain by declaration in one of the plugins like this:
<extension point="org.eclipse.emf.transaction.editingDomains">
<editingDomain id="com.example.shared.editingdomain"
factory="com.example.shared.SharedEditingDomainFactory"/>
</extension>
In the factory, simply call this to return a default factory:
// the factory implementation
public class SharedEditingDomainFactory extends
TransactionalEditingDomainImpl.FactoryImpl {
public TransactionalEditingDomain createEditingDomain() {
TransactionalEditingDomain result = super.createEditingDomain();
// customize my editing domain in some way
// ...
return result;
}
}
Now access the domain like this:
TransactionalEditingDomain domain =
TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
You can put this method in the EMF Editor, here:
@Override
public EditingDomain getEditingDomain() {
return
TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
}
In the EMF Editor, remove the editingDomain declaration/instantation,
make sure all depends use the getEditingDomain method.
Now the EMF, Editor should be more or less setup to use a shared
EditingDomain.
>>>>2
The GMF Editors, by default create a new Editing domain in the
xxxDocumentProvider class in the method createEditingDomain();
In that method, replace the code with the same as the EMF Editor:
public EditingDomain getEditingDomain() {
return
TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
}
In that method, a listener is registered to turn on Modification
Tracking, which you could just re-register on the shared editing domain.
>>>3 GMF can combine the semantic and diagram model into a single file
or keep it separate (This is an option in GMFGen). I recommend you keep
them separate, and use the resource from your EMF Editor as the semantic
resource for your GMF Editor. You will need to adapt a few things, like
the xxxEditorUtil->CreateDiagram() (Which actually creates a temporary
GMF Editing domain, but that is fine). It creates a semantic resource,
this is what you might want to change, by:
modelURI = "the URI of your file name in EMF Editor".
domain =
TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
domain.getResourceSet().getResource(modelURI, true);
As the Diagram model adds a semantic model object, the Semantic resource
will be resolved automatically by GMF, whenever it needs it.
>>>4 The GMF editor keeps track of the resource set in the
ResourceSetInfo. It registers a modification listener and fires if the
Editor is Dirty.
When sharing the editing domain and sharing the resource from the EMF
editor as the semantic model resource, the resouresetinfo needs to be
aware of this. Check the code in the ResourceSetInfo to see what happens
exactly and modify as needed. (For example also fire a dirty state for
the EMF editor).
Good luck with all this!
Christophe Bouhier
Timothy Marc wrote:
> Hi all,
>
> i tried to realize the integration of GMF and EMF editors as described
> here
> http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
> and in Richard's book. But both documents integrate the diagram editor
> into the EMF-generated editor. That's not what i want for my model. I'd
> like to have several diagrams (already implement) using the same
> TransactionEditingDomain as well as the EMF-generated editor.
>
> My first question is, is this possible or does sharing an editing domain
> implies sharing the editor itself.
>
> What i actually want to realize is to implement a context menu command,
> that is enabled for particular nodes. By executing such a command, a
> wizard should be open and provide the possibility to configure some
> internal stuff of the select node (respectively the underlying domain
> model element). Since these internal stuff is not part of the GMF
> diagram, i think i must retrieve the editing domain from the
> EMF-generated editor and execute all changes/modifications the user
> perform via its command stack. But how do i get the editing domain of
> the underlying model editor?! That's why i tried to create a single
> TransactionalEditingDomain for all diagrams and the EMF-generated editor...
>
> All eclipse ui stuuf (wizards, commands, etc.) is not a problem for me,
> but i have only minor experiences with GMF and EMF editing domains and
> no one with the EMF transaction framework in particular. I would
> appreciate it, if someone may verify or falsify my thoughts.
>
> Thanks a lot in advance
> Timothy
|
|
|
| Re: SHared EditingDomain [message #514329 is a reply to message #514282] |
Sun, 14 February 2010 12:43 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Hi Christopher,
thanks so far. It seems as this is requires really a lot of manual
modification. In particular, the registration of a
TransactionalEditingDomain as Extension wasn't shown in the GMF book.
However, for my second use case, that is changing the domain model and
indicate a dirty state to the EMF editor by introducing dialogs (with
some user-efined actions to be done for the domain elements), i think it
should work like this:
0. Registering a transactional editing domain as you told it
1. Registering a popup action for the desired domain element
2. Implement the dialog for the desired domain element
3. Get the TransactionEditingDomain like you mentioned:
TransactionalEditingDomain domain =
TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
in the dialog implementation, in order to propagte the modifications to
the EMF editor
4. Create commands for the changes the user performs in the dialog
5. Execute these commands via the TransactionEditingDomain so that they
are notified by each editor, working with this editing domain
(primarily, only the EMF editor)
Afterwards, at least the EMF editor should be notified that the domain
model was changed and should indicate the isDirty *. Do you agree or do
i missunderstand something? I would highly appreciate it if you could
give me a short statement concerning this.
By the way, have a nice valentin's day...
Timothy
Christophe Bouhier schrieb:
> Hi, here is what I recommend. (It took me some time to understand this
> well, so I might as well write it down).
>
> Option 1: Do it yourself by hand.
>
> 1. Make sure EMF' uses a Transactional Editing Domain.
> 2. Let the GMF Document provider also use the same editing domain.
> 3. Make sure the GMF Editor also use the semantic resource from the EMF
> editor. (Likely what you want).
> 4. GMF also uses a ResourceSetInfo, which needs to be carefully
> considered when Sharing an Editing domain.
>
>
> One thing to remember, is that the editing domain is there for the
> lifetime of the app. So, if you create resources from this domain's
> resourceset, you will need to make sure which ones are loaded/unloaded.
> (Check the dispose methods, for the EMF/GMF editors to see what happens
> to the resources).
>
>
> Option 2: Use GMFTools for item 2 above, which will require a bit more
> setup, as GMFTools, actually makes modifications in the templates to
> generate the code:
>
> See: http://code.google.com/p/gmftools/wiki/SharedEditingDomain
>
>
> Option 1:
> >>>>1
>
> Strip from the EMF Editor, the creation of an EditingDomain.
> Create an editing domain by declaration in one of the plugins like this:
>
> <extension point="org.eclipse.emf.transaction.editingDomains">
> <editingDomain id="com.example.shared.editingdomain"
> factory="com.example.shared.SharedEditingDomainFactory"/>
> </extension>
>
>
> In the factory, simply call this to return a default factory:
>
>
> // the factory implementation
> public class SharedEditingDomainFactory extends
> TransactionalEditingDomainImpl.FactoryImpl {
> public TransactionalEditingDomain createEditingDomain() {
> TransactionalEditingDomain result = super.createEditingDomain();
>
> // customize my editing domain in some way
> // ...
>
> return result;
> }
> }
>
>
>
> Now access the domain like this:
>
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>
>
> You can put this method in the EMF Editor, here:
>
> @Override
> public EditingDomain getEditingDomain() {
> return
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>
> }
>
>
> In the EMF Editor, remove the editingDomain declaration/instantation,
> make sure all depends use the getEditingDomain method.
>
> Now the EMF, Editor should be more or less setup to use a shared
> EditingDomain.
>
>
> >>>>2
>
> The GMF Editors, by default create a new Editing domain in the
> xxxDocumentProvider class in the method createEditingDomain();
>
> In that method, replace the code with the same as the EMF Editor:
>
>
> public EditingDomain getEditingDomain() {
> return
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>
> }
>
> In that method, a listener is registered to turn on Modification
> Tracking, which you could just re-register on the shared editing domain.
>
>
> >>>3 GMF can combine the semantic and diagram model into a single file
> or keep it separate (This is an option in GMFGen). I recommend you keep
> them separate, and use the resource from your EMF Editor as the semantic
> resource for your GMF Editor. You will need to adapt a few things, like
> the xxxEditorUtil->CreateDiagram() (Which actually creates a temporary
> GMF Editing domain, but that is fine). It creates a semantic resource,
> this is what you might want to change, by:
>
> modelURI = "the URI of your file name in EMF Editor".
> domain =
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>
> domain.getResourceSet().getResource(modelURI, true);
>
> As the Diagram model adds a semantic model object, the Semantic resource
> will be resolved automatically by GMF, whenever it needs it.
>
> >>>4 The GMF editor keeps track of the resource set in the
> ResourceSetInfo. It registers a modification listener and fires if the
> Editor is Dirty.
>
> When sharing the editing domain and sharing the resource from the EMF
> editor as the semantic model resource, the resouresetinfo needs to be
> aware of this. Check the code in the ResourceSetInfo to see what happens
> exactly and modify as needed. (For example also fire a dirty state for
> the EMF editor).
>
> Good luck with all this!
> Christophe Bouhier
>
>
>
>
>
> Timothy Marc wrote:
>> Hi all,
>>
>> i tried to realize the integration of GMF and EMF editors as described
>> here
>> http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
>> and in Richard's book. But both documents integrate the diagram editor
>> into the EMF-generated editor. That's not what i want for my model.
>> I'd like to have several diagrams (already implement) using the same
>> TransactionEditingDomain as well as the EMF-generated editor.
>>
>> My first question is, is this possible or does sharing an editing
>> domain implies sharing the editor itself.
>>
>> What i actually want to realize is to implement a context menu
>> command, that is enabled for particular nodes. By executing such a
>> command, a wizard should be open and provide the possibility to
>> configure some internal stuff of the select node (respectively the
>> underlying domain model element). Since these internal stuff is not
>> part of the GMF diagram, i think i must retrieve the editing domain
>> from the EMF-generated editor and execute all changes/modifications
>> the user perform via its command stack. But how do i get the editing
>> domain of the underlying model editor?! That's why i tried to create a
>> single TransactionalEditingDomain for all diagrams and the
>> EMF-generated editor...
>>
>> All eclipse ui stuuf (wizards, commands, etc.) is not a problem for
>> me, but i have only minor experiences with GMF and EMF editing domains
>> and no one with the EMF transaction framework in particular. I would
>> appreciate it, if someone may verify or falsify my thoughts.
>>
>> Thanks a lot in advance
>> Timothy
|
|
|
| Re: SHared EditingDomain [message #514591 is a reply to message #514329] |
Mon, 15 February 2010 16:36 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Inline comments below.
Timothy Marc wrote:
> Hi Christopher,
>
> thanks so far. It seems as this is requires really a lot of manual
> modification. In particular, the registration of a
> TransactionalEditingDomain as Extension wasn't shown in the GMF book.
>
In the book, both the EMF and GMF Editor are in the same multipage Edit
part. So they both have the same lifecycle. When separating the editors,
the requirement is different, hence the proposed. BTW, this is nicely
documented in the EMF Model Transaction help.
> However, for my second use case, that is changing the domain model and
> indicate a dirty state to the EMF editor by introducing dialogs (with
> some user-efined actions to be done for the domain elements), i think it
> should work like this:
>
> 0. Registering a transactional editing domain as you told it
> 1. Registering a popup action for the desired domain element
> 2. Implement the dialog for the desired domain element
> 3. Get the TransactionEditingDomain like you mentioned:
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>
> in the dialog implementation, in order to propagte the modifications to
> the EMF editor
> 4. Create commands for the changes the user performs in the dialog
Yes, if it's a wizard, in performFinish(), you could execute the
commands there.
> 5. Execute these commands via the TransactionEditingDomain so that they
> are notified by each editor, working with this editing domain
> (primarily, only the EMF editor)
>
> Afterwards, at least the EMF editor should be notified that the domain
> model was changed and should indicate the isDirty *. Do you agree or do
> i missunderstand something? I would highly appreciate it if you could
> give me a short statement concerning this.
>
One thing here, and I am still haven't figured it out exactly, but in my
case, the registered listener on the commandstack (In the EMF Editor in
method initializeDomain(), is not called when the commands initiate from
the EMF Editor. This listener fires this:
firePropertyChange(IEditorPart.PROP_DIRTY);
> By the way, have a nice valentin's day...
Thanks! It was fun.
>
> Timothy
>
>
>
> Christophe Bouhier schrieb:
>> Hi, here is what I recommend. (It took me some time to understand this
>> well, so I might as well write it down).
>>
>> Option 1: Do it yourself by hand.
>>
>> 1. Make sure EMF' uses a Transactional Editing Domain.
>> 2. Let the GMF Document provider also use the same editing domain.
>> 3. Make sure the GMF Editor also use the semantic resource from the
>> EMF editor. (Likely what you want).
>> 4. GMF also uses a ResourceSetInfo, which needs to be carefully
>> considered when Sharing an Editing domain.
>>
>>
>> One thing to remember, is that the editing domain is there for the
>> lifetime of the app. So, if you create resources from this domain's
>> resourceset, you will need to make sure which ones are loaded/unloaded.
>> (Check the dispose methods, for the EMF/GMF editors to see what
>> happens to the resources).
>>
>>
>> Option 2: Use GMFTools for item 2 above, which will require a bit more
>> setup, as GMFTools, actually makes modifications in the templates to
>> generate the code:
>>
>> See: http://code.google.com/p/gmftools/wiki/SharedEditingDomain
>>
>>
>> Option 1:
>> >>>>1
>>
>> Strip from the EMF Editor, the creation of an EditingDomain.
>> Create an editing domain by declaration in one of the plugins like this:
>>
>> <extension point="org.eclipse.emf.transaction.editingDomains">
>> <editingDomain id="com.example.shared.editingdomain"
>> factory="com.example.shared.SharedEditingDomainFactory"/>
>> </extension>
>>
>>
>> In the factory, simply call this to return a default factory:
>>
>>
>> // the factory implementation
>> public class SharedEditingDomainFactory extends
>> TransactionalEditingDomainImpl.FactoryImpl {
>> public TransactionalEditingDomain createEditingDomain() {
>> TransactionalEditingDomain result = super.createEditingDomain();
>>
>> // customize my editing domain in some way
>> // ...
>>
>> return result;
>> }
>> }
>>
>>
>>
>> Now access the domain like this:
>>
>> TransactionalEditingDomain domain =
>> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>>
>>
>> You can put this method in the EMF Editor, here:
>>
>> @Override
>> public EditingDomain getEditingDomain() {
>> return
>> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>>
>> }
>>
>>
>> In the EMF Editor, remove the editingDomain declaration/instantation,
>> make sure all depends use the getEditingDomain method.
>>
>> Now the EMF, Editor should be more or less setup to use a shared
>> EditingDomain.
>>
>>
>> >>>>2
>>
>> The GMF Editors, by default create a new Editing domain in the
>> xxxDocumentProvider class in the method createEditingDomain();
>>
>> In that method, replace the code with the same as the EMF Editor:
>>
>>
>> public EditingDomain getEditingDomain() {
>> return
>> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>>
>> }
>>
>> In that method, a listener is registered to turn on Modification
>> Tracking, which you could just re-register on the shared editing domain.
>>
>>
>> >>>3 GMF can combine the semantic and diagram model into a single
>> file or keep it separate (This is an option in GMFGen). I recommend
>> you keep them separate, and use the resource from your EMF Editor as
>> the semantic resource for your GMF Editor. You will need to adapt a
>> few things, like the xxxEditorUtil->CreateDiagram() (Which actually
>> creates a temporary GMF Editing domain, but that is fine). It creates
>> a semantic resource, this is what you might want to change, by:
>>
>> modelURI = "the URI of your file name in EMF Editor".
>> domain =
>> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "com.example.shared.editingdomain");
>>
>> domain.getResourceSet().getResource(modelURI, true);
>>
>> As the Diagram model adds a semantic model object, the Semantic
>> resource will be resolved automatically by GMF, whenever it needs it.
>>
>> >>>4 The GMF editor keeps track of the resource set in the
>> ResourceSetInfo. It registers a modification listener and fires if the
>> Editor is Dirty.
>>
>> When sharing the editing domain and sharing the resource from the EMF
>> editor as the semantic model resource, the resouresetinfo needs to be
>> aware of this. Check the code in the ResourceSetInfo to see what
>> happens exactly and modify as needed. (For example also fire a dirty
>> state for the EMF editor).
>>
>> Good luck with all this!
>> Christophe Bouhier
>>
>>
>>
>>
>>
>> Timothy Marc wrote:
>>> Hi all,
>>>
>>> i tried to realize the integration of GMF and EMF editors as
>>> described here
>>> http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
>>> and in Richard's book. But both documents integrate the diagram
>>> editor into the EMF-generated editor. That's not what i want for my
>>> model. I'd like to have several diagrams (already implement) using
>>> the same TransactionEditingDomain as well as the EMF-generated editor.
>>>
>>> My first question is, is this possible or does sharing an editing
>>> domain implies sharing the editor itself.
>>>
>>> What i actually want to realize is to implement a context menu
>>> command, that is enabled for particular nodes. By executing such a
>>> command, a wizard should be open and provide the possibility to
>>> configure some internal stuff of the select node (respectively the
>>> underlying domain model element). Since these internal stuff is not
>>> part of the GMF diagram, i think i must retrieve the editing domain
>>> from the EMF-generated editor and execute all changes/modifications
>>> the user perform via its command stack. But how do i get the editing
>>> domain of the underlying model editor?! That's why i tried to create
>>> a single TransactionalEditingDomain for all diagrams and the
>>> EMF-generated editor...
>>>
>>> All eclipse ui stuuf (wizards, commands, etc.) is not a problem for
>>> me, but i have only minor experiences with GMF and EMF editing
>>> domains and no one with the EMF transaction framework in particular.
>>> I would appreciate it, if someone may verify or falsify my thoughts.
>>>
>>> Thanks a lot in advance
>>> Timothy
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:56:54 GMT 2024
Powered by FUDForum. Page generated in 0.04079 seconds |
] 
Search
Help
Register
Login
Home
