Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356291

Summary:

Using "proxy" attributes that resolve to a FeatureMap (by namespace resolution), the SetCommand fails

Product:

[Modeling] EMF

Reporter:

Mickael Istria <mistria>

Component:

Edit

Assignee:

Ed Merks <Ed.Merks>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

faure.tristan, mathieu.velten

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
Suggested tests that shows different behavior between normal and transactional	none
Suggested fix on the SetCommand class to check also affiliation for a dynamic feature	none
fix null feature	none

Description Mickael Istria

2011-08-31 05:23:03 EDT

From forum thread: http://www.eclipse.org/forums/index.php/t/237622/

I am trying to use dynamic attributes to "wrap" manipulation of a
FeatureMap I have in my metamodel.

Let's say that I have an Element MyElement, which has a mixed featureMap
called "group". Then I want to manipulate this "group" with dynamic
annotated EAttributes, so that I can perform eGet and eSet directly on
my eObject and it resolves the values in my group (through the eOpenSet
method). Out of the transactional world, with eGet, eSet and so on,
everything is working fine.

However, when I want to use the SetCommand, it fails because of a check
on the static class.

This makes impossible to use EMF DataBinding with FeatureMaps.

Comment 1 Mickael Istria

2011-08-31 12:49:27 EDT

*** Bug 356293 has been marked as a duplicate of this bug. ***

Comment 2 Mickael Istria

2011-08-31 12:58:12 EDT

Created attachment 202542 [details]
Suggested tests that shows different behavior between normal and transactional

This is a couple of test that perform the same operation in a non-transactional and a transactional context, with different behavior.
It highlights that the canExecute method of SetCommand is too constraining.

Comment 3 Mickael Istria

2011-08-31 13:28:27 EDT

Created attachment 202546 [details]
Suggested fix on the SetCommand class to check also affiliation for a dynamic feature

In case the feature is not part of the static class, this simply checks whether the affiliation of the feature is part of it.

Comment 4 Mickael Istria

2011-09-12 11:48:34 EDT

Ed,

Did you have time to have a look to suggested patches?
I'd really like to see this fixed in upcoming SR1 if it is still possible.

Comment 5 Ed Merks

2011-09-12 13:23:53 EDT

I'm quite sure that feature maps where never designed to handle proxy resolution so it won't be easy to fix.  Unfortunately I'm extremely busy right now and won't have time to look into it in time for SR1.

Comment 6 Mickael Istria

2011-09-13 03:43:41 EDT

In case you missed it, 2 weeks ago, I provided unit tests and a patch to have SetCommand working for the use case I describe. Fixing it would be just reviewing and applying these patches.
I can understand it is a bit late to get it into SR1, too bad...

Comment 7 Ed Merks

2011-09-13 11:49:02 EDT

I committed the fix for 2.7.1 and 2.8.0.

Comment 8 Mickael Istria

2011-09-13 12:00:18 EDT

Thanks a lot Ed!

Comment 9 Ed Merks

2011-09-24 11:13:08 EDT

The changes are available in 2.7.1 and 2.8.0 builds.

Comment 10 Mathieu Velten

2011-10-13 10:30:21 EDT

Created attachment 205133 [details]
fix null feature

Comment 11 Mathieu Velten

2011-10-13 10:30:46 EDT

This patch introduces a big regression : it assumes feature is not null, while SetCommand.create with feature null is used a lot in the EMF code itself.

patch attached.

Comment 12 Mathieu Velten

2011-10-13 10:32:55 EDT

I think

Comment 13 Mathieu Velten

2011-10-13 10:36:20 EDT

I think it is a really big regression that can have a lot of impacts.
It brokes the DnD in all our GEF editors since DragAndDropCommand uses it.