Eclipse Community Forums: EMF Parsley » Treeviewer Other Editing Domain

Home » Modeling » EMF Parsley » Treeviewer Other Editing Domain(Using a specific transactional editing domain with treeviewer context menu)

Show: Today's Messages :: Show Polls :: Message Navigator

Treeviewer Other Editing Domain [message #1708923]

Tue, 22 September 2015 13:39

Martin Jonsson

Messages: 21
Registered: March 2013

Junior Member

Hello all.

I'm using EMF Parsley together with the eclipse BPMN2 modeler to model a view on extension data. A particularity of this is that it uses a specific transactional editing domain without which you cannot save the data.

By extending the EditDomainFinder to get this editing domain from the EObject, for existing objects, all goes well. However, for objects that are added through the context menu, it does not work at all.

1) The editing domain for the context menu is specified with the context menu helper. This must be a AdapterFactoryEditingDomain. This is not dependant on the EObject and leads to different save commands for the added entry and the other modifications in the model. This leads to dreaded "not write command" error.

2) By trying to overcome this by extending the EditingMenuBuilder and putting the correct editing domain, I get a EMF EDIT error that the string representation of the feature is incorrect. It truly expects a AdapterFactoryEditingDomain.

Is it possible to add a specific Transational Editing Domain also for the context menu? Otherwise, integrated scenarios for treeviewer that are not based on the EMF Edit editors are impossible.

Many thanks
Martin

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1708992 is a reply to message #1708923]

Wed, 23 September 2015 07:50

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 22/09/2015 15:39, Martin Jonsson wrote:
> Hello all.
>
> I'm using EMF Parsley together with the eclipse BPMN2 modeler to model a
> view on extension data. A particularity of this is that it uses a
> specific transactional editing domain without which you cannot save the
> data.
>
> By extending the EditDomainFinder to get this editing domain from the
> EObject, for existing objects, all goes well. However, for objects that
> are added through the context menu, it does not work at all.
>
> 1) The editing domain for the context menu is specified with the context
> menu helper. This must be a AdapterFactoryEditingDomain. This is not
> dependant on the EObject and leads to different save commands for the
> added entry and the other modifications in the model. This leads to
> dreaded "not write command" error.
>
> 2) By trying to overcome this by extending the EditingMenuBuilder and
> putting the correct editing domain, I get a EMF EDIT error that the
> string representation of the feature is incorrect. It truly expects a
> AdapterFactoryEditingDomain.
>
> Is it possible to add a specific Transational Editing Domain also for
> the context menu? Otherwise, integrated scenarios for treeviewer that
> are not based on the EMF Edit editors are impossible.

Hi Martin

could you please provide some more information about the errors? A
stack trace would be nice, to help us understand whether we can relax
the requirement for an AdapterFactoryEditingDomain. Note that context
menu construction, unless customized, simply delegate to the standard
EMF.Edit behavior.

Also, a small reproducible example using a transaction editing domain
would be good.

Thanks in advance
cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1709399 is a reply to message #1708992]

Mon, 28 September 2015 09:02

Martin Jonsson

Messages: 21
Registered: March 2013

Junior Member

Hello Lorenzo.

Sorry for the late reply, I was on travel for a few days.

I added stacktrace but manageble example is somewhat hard. You need to:

1 install the eclipse BPMN2 modeler
2 add extension element to the BPMN model via a custom model
3 Create parsley view on this custom model

So I don't know this is possible without posting my complete plugin. So if you can figure out something from the stacktrace, that is great, otherwise we have to try something more complicated.

Cheers
Martin

Attachment: stacktrace
(Size: 8.68KB, Downloaded 154 times)

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1709433 is a reply to message #1709399]

Mon, 28 September 2015 11:49

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 28/09/2015 11:03, Martin Jonsson wrote:
> Hello Lorenzo.
>
> Sorry for the late reply, I was on travel for a few days.
>
> I added stacktrace but manageble example is somewhat hard. You need to:
>
> 1 install the eclipse BPMN2 modeler
> 2 add extension element to the BPMN model via a custom model
> 3 Create parsley view on this custom model
>
> So I don't know this is possible without posting my complete plugin. So if you can figure out something from the stacktrace, that is great, otherwise we have to try something more complicated.
>
> Cheers
> Martin
>

Hi Martin

the relevant part of the stacktrace is this one

Caused by: java.lang.IllegalStateException: Cannot modify resource set
without a write transaction
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.assertWriting(TransactionChangeRecorder.java:348)
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.appendNotification(TransactionChangeRecorder.java:302)
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.processObjectNotification(TransactionChangeRecorder.java:284)
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.notifyChanged(TransactionChangeRecorder.java:240)
at
org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
at
org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(EcoreEList.java:249)
at
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:457)
at
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:400)
at org.eclipse.emf.common.util.AbstractEList.addAll(AbstractEList.java:370)
at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand.java:399)

but this seems to indicate that the transactional editing domain is not
used, otherwise I guess the standard EMF command would be executed in a
transaction, wouldn't they?

I mean, in the stacktrace Parsley is not involved at all.

So this stacktrace does not seem to be related to your original post (I
seem to recall that you manage to force to use a transactional editing
domain), or did I miss something?

Please keep in mind that I have no experience with transactional editing
domains, that's why I asked for a small example. I don't think all the
BPMN2 modeler is required: just an example using transactional editing
domain.

hope to hear from you soon

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1709672 is a reply to message #1709433]

Wed, 30 September 2015 08:38

Martin Jonsson

Messages: 21
Registered: March 2013

Junior Member

Hello Lorenzo.

You are correct that the trace has nothing to do with Parsley.

The problem is as follows:

1) Parent EObject that belongs to a BPMN2 Transaction Domain.

2) Context menu adds a child EObject that belongs to a Parsley Abstract Editing Domain.

3) When the child object is appended as containment reference to the parent, EMF complains that there is no write command, which is correct, because the write command belongs to the child editing domain and not the parent editing domain.

So without the ability to set the editing domain at runtime, as a transactional editing domain from the parent, I cannot see how to use EMF parsley in more specialized scenarios than normal EMF Editors.

PS. The problem is also described in GMF - EMF integration on the following page:
http://www.eclipse.org/articles/Article-Integrating-EMF-GMF-Editors/#upgrading_the_editing_domain

under the "Upgrading the Editing Domain" section.

Hope you see the problem better now.
Cheers
Martin

[Updated on: Wed, 30 September 2015 08:51]

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1709787 is a reply to message #1709672]

Thu, 01 October 2015 06:51

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 30/09/2015 10:38, Martin Jonsson wrote:
> Hello Lorenzo.
>
> You are correct that the trace has nothing to do with Parsley.
>
> The problem is as follows:
>
> 1) Parent EObject that belongs to a BPMN2 Transaction Domain.
>
> 2) Context menu adds a child EObject that belongs to a Parsley Abstract
> Editing Domain.
>
> 3) When the child object is appended as containment reference to the
> parent, EMF complains that there is no write command, which is correct,
> because the write command belongs to the child editing domain and not
> the parent editing domain.
>
> So without the ability to set the editing domain at runtime, as a
> transactional editing domain from the parent, I cannot see how to use
> EMF parsley in more specialized scenarios than normal EMF Editors.
>

Hi Martin

so we could try to relax the assumption that the editing domain is an
adapter factory editing domain, from what I understand, so that you'll
be able to pass a transaction editing domain.

is that correct?

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1710931 is a reply to message #1709787]

Sun, 11 October 2015 10:44

Martin Jonsson

Messages: 21
Registered: March 2013

Junior Member

Hello Lorenzo.

Sorry for the late reply. I was on vacation.

Yes that is correct.

However, I would like another thing as well: That the editing domain can be determined when used and not at the creation time. This condition I can override with the menu extension functionality but it would be better to set it when the EMF object is determined.

Many thanks for your help!
Martin

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1711113 is a reply to message #1710931]

Tue, 13 October 2015 07:29

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 11/10/2015 12:44, Martin Jonsson wrote:
> Hello Lorenzo.
>
> Sorry for the late reply. I was on vacation.
> Yes that is correct.
>
> However, I would like another thing as well: That the editing domain can
> be determined when used and not at the creation time. This condition I
> can override with the menu extension functionality but it would be
> better to set it when the EMF object is determined.
>
> Many thanks for your help!
> Martin

Hi Martin

can you please be more specific about "determined when used"?

By the way, in the meantime I created a bug related to this discussion
https://bugs.eclipse.org/bugs/show_bug.cgi?id=479557

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1712906 is a reply to message #1710931]

Thu, 29 October 2015 09:41

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 11/10/2015 12:44, Martin Jonsson wrote:
> Hello Lorenzo.
>
> Sorry for the late reply. I was on vacation.
> Yes that is correct.
>
> However, I would like another thing as well: That the editing domain can
> be determined when used and not at the creation time. This condition I
> can override with the menu extension functionality but it would be
> better to set it when the EMF object is determined.
>
> Many thanks for your help!
> Martin

OK, now I think I understand what you mean for retrieving the editing
domain when the object is determined.

I created a specific bug for that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=480964

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1723157 is a reply to message #1710931]

Fri, 12 February 2016 09:07

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 11/10/2015 12:44, Martin Jonsson wrote:
> Hello Lorenzo.
>
> Sorry for the late reply. I was on vacation.
> Yes that is correct.
>
> However, I would like another thing as well: That the editing domain can
> be determined when used and not at the creation time. This condition I
> can override with the menu extension functionality but it would be
> better to set it when the EMF object is determined.
>
> Many thanks for your help!
> Martin

Hi Martin

these things are now part of the new released 0.6.0.

Have you tried that?

cheers
Lorenzo

--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1723391 is a reply to message #1708923]

Mon, 15 February 2016 11:19

Martin Jonsson

Messages: 21
Registered: March 2013

Junior Member

Hello Lorenzo.

Working on it. Many thanks!

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1723405 is a reply to message #1723391]

Mon, 15 February 2016 12:17

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 15/02/2016 12:19, Martin Jonsson wrote:
> Hello Lorenzo.
>
> Working on it. Many thanks!

OK, please keep me posted.

Please also make sure to have a look at the migration guide in the
Eclipse documentation.

cheers
Lorenzo

--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1725632 is a reply to message #1723405]

Sat, 05 March 2016 11:22

Martin Jonsson

Messages: 21
Registered: March 2013

Junior Member

Hello.

Tested it with version 0.6 and works like a charm.

Many thanks for the update.

Martin

Report message to a moderator

Re: Treeviewer Other Editing Domain [message #1725746 is a reply to message #1725632]

Mon, 07 March 2016 12:07

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 05/03/2016 12:22, Martin Jonsson wrote:
> Hello.
>
> Tested it with version 0.6 and works like a charm.
>
> Many thanks for the update.
>
> Martin

Thank you Martin for the feedback :)

--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book

Report message to a moderator

Previous Topic:	New versions available, Neon train & newsletter link
Next Topic:	Table with nested attributes

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Dec 06 22:22:55 GMT 2023

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter