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  |
|
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  |
 Ed Merks
Messages: 33142
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...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
|
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
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 17:12:14 GMT 2024
Powered by FUDForum. Page generated in 0.02938 seconds |
] 
Search
Help
Register
Login
Home
