Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Prevent elements to be moved from one container to another
Prevent elements to be moved from one container to another [message #1219535] Wed, 04 December 2013 13:31 Go to next message
Jens von Pilgrim is currently offline Jens von PilgrimFriend
Messages: 313
Registered: July 2009
Senior Member
Hi,

In my model, I have containment references. E.g.

class A {
contains B[] bs
}

class B{}

Now I want to prevent Bs to be (accidentally) moved from one container
to another. It should be possible to add and remove bs from a, but not
to move an B instance from one container to another.

This should be possible by slightly enhancing the model, e.g.

abstract class NonMoveableElement{}
class B extends NonMoveableElement{}

and by providing a custom implementation for NonMoveableElement, overriding

org.eclipse.emf.ecore.impl.MinimalEObjectImpl.eBasicSetContainer(InternalEObject)

(with a version throwing an exception if there is a container and if it
is changed (and not set to null)).

However, this custom class may be without effect in case of a more
complicated model with multi-inheritance. Besides, I would assume that
this is a common problem, so there might be a general more "model"-like
solution for that (e.g., an annotation). Is there such as solution?

Regards,
Jens

PS: I'm aware of the nice utility class EcoreUtil.copy, and even better
EcoreUtil2.cloneIfContained (an Xtext utility class), which can be used
to prevent the situation in the first place. Unfortunately, one
sometimes forget to use these nice methods...
Re: Prevent elements to be moved from one container to another [message #1219540 is a reply to message #1219535] Wed, 04 December 2013 14:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30544
Registered: July 2009
Senior Member
Jens,

Comments below.

On 04/12/2013 2:31 PM, Jens v.P. wrote:
> Hi,
>
> In my model, I have containment references. E.g.
>
> class A {
> contains B[] bs
> }
>
> class B{}
>
> Now I want to prevent Bs to be (accidentally) moved from one container
> to another.
When might this accident happen. The user in the editor? Or the
developer using the API?
> It should be possible to add and remove bs from a, but not to move an
> B instance from one container to another.
That sounds tricky. After all, this don't necessarily happen with just
a single "operation". In the editor you could use Cut and then Paste,
in the API you can do a remove followed by an add.
>
> This should be possible by slightly enhancing the model, e.g.
>
> abstract class NonMoveableElement{}
> class B extends NonMoveableElement{}
>
> and by providing a custom implementation for NonMoveableElement,
> overriding
>
> org.eclipse.emf.ecore.impl.MinimalEObjectImpl.eBasicSetContainer(InternalEObject)
>
That sounds frightening.
>
> (with a version throwing an exception if there is a container and if
> it is changed (and not set to null)).
And again, you're likely to find the container is set to null and then
later set to something else...
>
> However, this custom class may be without effect in case of a more
> complicated model with multi-inheritance. Besides, I would assume that
> this is a common problem,
No, it seems a bit fishy...
> so there might be a general more "model"-like solution for that (e.g.,
> an annotation). Is there such as solution?
No, I'm not sure how it's really sensible given that the fine grained
transitions, add/remove are to be allowed, and there isn't generally a
higher level transition of "move"...
>
> Regards,
> Jens
>
> PS: I'm aware of the nice utility class EcoreUtil.copy, and even
> better EcoreUtil2.cloneIfContained (an Xtext utility class), which can
> be used to prevent the situation in the first place. Unfortunately,
> one sometimes forget to use these nice methods...
Are you just trying to find bugs? Perhaps there are objects you want
to make "read-only" to find bugs? One approach for that is to attach an
EContentAdapter that throws exceptions for any notifyChanged calls...
Re: Prevent elements to be moved from one container to another [message #1219546 is a reply to message #1219540] Wed, 04 December 2013 14:51 Go to previous messageGo to next message
Jens von Pilgrim is currently offline Jens von PilgrimFriend
Messages: 313
Registered: July 2009
Senior Member
Ed,

Actually, yes, I "only" try to find bugs ;-)

I probably didn't explained the context: it's Xtext. And the element I
want to be restricted from being moved are elements serving as (type)
references. This is a (simplified) snippet of my grammar and model:

VarDecl: typeRef=TypeRef varName=ID
TypeRef: declaredType=[Type|ID]

So, this is my model:

class VarDecl {
contains TypeRef typeRef
String name
}

class TypeRef {
references Type
}

class Type {
String name
}

A typeref must never be moved from one variable to another. This could
easily happen by accident, e.g., during type inference or binding.

In general, adding content adapters might be a good solution. But in
this specific case, in which there are literally thousands of TypeRef
instances, I would prefer to have a class based solution.

But I agree of course, my case seems quite special. Actually, before we
decided to use EMF for modeling our type model, we were already worried
about this containment problem with regard to type references...

On 04.12.13 15:06, Ed Merks wrote:
>> overriding
>>
>> org.eclipse.emf.ecore.impl.MinimalEObjectImpl.eBasicSetContainer(InternalEObject)
>>
> That sounds frightening.

Hehe... maybe I will give it a try, just for finding bugs and for
writing a little horror story :-D
icon5.gif  Re: Prevent elements to be moved from one container to another [message #1418761 is a reply to message #1219546] Sun, 07 September 2014 15:57 Go to previous message
Erick Hagstrom is currently offline Erick HagstromFriend
Messages: 108
Registered: April 2014
Location: USA
Senior Member
Hi Jens Cool

Just curious. How did this turn out? Halloween is approaching, and (at least in the US) that's a good time for horror stories Twisted Evil
Previous Topic:[CDO] CommitIntegrityException while using transaction.setCommittables
Next Topic:Understanding CDODataOutputImpl and CDODataInputImpl classes' methods
Goto Forum:
  


Current Time: Tue Oct 15 11:39:59 GMT 2019

Powered by FUDForum. Page generated in 0.01633 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top