Home » Modeling » EMF » DeleteCommand
| DeleteCommand [message #425409] |
Tue, 25 November 2008 16:07  |
Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Hi!
A DeleteCommand "removes an object from its parent container and deletes
all other references to it from within the editing domain".
But it seems that if the object is not contained by another model
object, or if the object is contained by a resource object, the
DeleteCommand becomes unexecutable because the RemoveCommand creation
(which is meant to remove the object from it's container) returns an
UnexecutableCommand.
Is this really the expected behaviour of DeleteCommand ?
I thought that even if the object cannot be removed from a container, it
still has to be de-referenced from other objects of the editing domain.
Am I wrong ?
If I am, then, should I create another command which does what I need,
or is there something I'm missing ?
Thank you !
Stephane
|
|
| |
| Re: DeleteCommand [message #425436 is a reply to message #425420] |
Wed, 26 November 2008 10:05  |
| Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Hi Ed,
Comments below...
Ed Merks wrote :
> Stephane,
>
> Comments below.
>
>
> SWT wrote:
>> Hi!
>>
>> A DeleteCommand "removes an object from its parent container and
>> deletes all other references to it from within the editing domain".
>> But it seems that if the object is not contained by another model
>> object, or if the object is contained by a resource object, the
>> DeleteCommand becomes unexecutable because the RemoveCommand creation
>> (which is meant to remove the object from it's container) returns an
>> UnexecutableCommand.
>>
>> Is this really the expected behaviour of DeleteCommand ?
> Yes, because we have no support for creating a new object in the
> resource. Deleting one would leave you in a state where you could not
> ever add one.
I don't know if I understand well.
Creating a new object in a resource is just something like :
resource.getContents().add(FooFactory.eINSTANCE.createFoo()) ;
If I delete the created "foo" object. There's nothing preventing me from
adding another one later...
I'm sure I'm missing something important here...
>> I thought that even if the object cannot be removed from a container,
>> it still has to be de-referenced from other objects of the editing
>> domain. Am I wrong ?
>> If I am, then, should I create another command which does what I need,
>> or is there something I'm missing ?
> What will you do with the empty resource? It's not valid XML in general
> to have no root object?
There may be multiple root objects in a single resource (I can call
getContents().add(...) multiple times).
Removing an object doesn't always lead to an empty resource.
And even if I have an empty resource, I can discard it, since it is empty...
I can't see the problem(s) here...
Note that I'm not used to XML issues since I use Resource objects that
delegates to an EStore (but I will have to handle XML in a few days...)
>>
>> Thank you !
>> Stephane
>>
Thanks again !
|
|
|
| Re: DeleteCommand [message #425445 is a reply to message #425436] |
Wed, 26 November 2008 13:43 |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Stephane,
Comments below.
SWT wrote:
> Hi Ed,
>
> Comments below...
>
> Ed Merks wrote :
>> Stephane,
>>
>> Comments below.
>>
>>
>> SWT wrote:
>>> Hi!
>>>
>>> A DeleteCommand "removes an object from its parent container and
>>> deletes all other references to it from within the editing domain".
>>> But it seems that if the object is not contained by another model
>>> object, or if the object is contained by a resource object, the
>>> DeleteCommand becomes unexecutable because the RemoveCommand
>>> creation (which is meant to remove the object from it's container)
>>> returns an UnexecutableCommand.
>>>
>>> Is this really the expected behaviour of DeleteCommand ?
>> Yes, because we have no support for creating a new object in the
>> resource. Deleting one would leave you in a state where you could
>> not ever add one.
> I don't know if I understand well.
> Creating a new object in a resource is just something like :
> resource.getContents().add(FooFactory.eINSTANCE.createFoo()) ;
> If I delete the created "foo" object. There's nothing preventing me
> from adding another one later...
> I'm sure I'm missing something important here...
Indeed. But given that a resource can hold any type of object, this
would tend to imply that I can create an instance of any class of any
model. You'll notice that pop up menu in a resource doesn't by default
allow a child object to be created. Specializing your resource item
provider to support creation and deletion is certainly possible though
>
>>> I thought that even if the object cannot be removed from a
>>> container, it still has to be de-referenced from other objects of
>>> the editing domain. Am I wrong ?
>>> If I am, then, should I create another command which does what I
>>> need, or is there something I'm missing ?
>> What will you do with the empty resource? It's not valid XML in
>> general to have no root object?
> There may be multiple root objects in a single resource (I can call
> getContents().add(...) multiple times).
Yes, although XMLResourceImpl doesn't like that while XMIResourceImpl
doesn't mind (because it creates a "fake" XMI root element).
> Removing an object doesn't always lead to an empty resource.
> And even if I have an empty resource, I can discard it, since it is
> empty...
Yes, but what does saving the empty resource imply? A empty file isn't
valid XML...
> I can't see the problem(s) here...
That's because you haven't tried it all yet. :-P
>
> Note that I'm not used to XML issues since I use Resource objects that
> delegates to an EStore (but I will have to handle XML in a few days...)
>
>>>
>>> Thank you !
>>> Stephane
>>>
> Thanks again !
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: DeleteCommand [message #425462 is a reply to message #425445] |
Wed, 26 November 2008 18:28 |
| Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Ed,
Comments below.
Ed Merks wrote :
> Stephane,
>
> Comments below.
>
> SWT wrote:
>> Hi Ed,
>>
>> Comments below...
>>
>> Ed Merks wrote :
>>> Stephane,
>>>
>>> Comments below.
>>>
>>>
>>> SWT wrote:
>>>> Hi!
>>>>
>>>> A DeleteCommand "removes an object from its parent container and
>>>> deletes all other references to it from within the editing domain".
>>>> But it seems that if the object is not contained by another model
>>>> object, or if the object is contained by a resource object, the
>>>> DeleteCommand becomes unexecutable because the RemoveCommand
>>>> creation (which is meant to remove the object from it's container)
>>>> returns an UnexecutableCommand.
>>>>
>>>> Is this really the expected behaviour of DeleteCommand ?
>>> Yes, because we have no support for creating a new object in the
>>> resource. Deleting one would leave you in a state where you could
>>> not ever add one.
>> I don't know if I understand well.
>> Creating a new object in a resource is just something like :
>> resource.getContents().add(FooFactory.eINSTANCE.createFoo()) ;
>> If I delete the created "foo" object. There's nothing preventing me
>> from adding another one later...
>> I'm sure I'm missing something important here...
> Indeed. But given that a resource can hold any type of object, this
> would tend to imply that I can create an instance of any class of any
> model.
Yes. Is that a problem ?
> You'll notice that pop up menu in a resource doesn't by default
> allow a child object to be created. Specializing your resource item
> provider to support creation and deletion is certainly possible though
Yes, this is kind of what I do in my app :
I'm not using the resource item provider since my viewer's inputs are
not resources, but I allow creation and deletion of objects.
I can use my resource implementation to create a model object. In this
case, the new object may be added to the resource's contents list.
I can also create a model object with the generated EFactory. Then the
object doesn't belong to any resource until it becomes referred by
another object which belongs to a resource (then it is "attached" to the
resource).
>>
>>>> I thought that even if the object cannot be removed from a
>>>> container, it still has to be de-referenced from other objects of
>>>> the editing domain. Am I wrong ?
>>>> If I am, then, should I create another command which does what I
>>>> need, or is there something I'm missing ?
>>> What will you do with the empty resource? It's not valid XML in
>>> general to have no root object?
>> There may be multiple root objects in a single resource (I can call
>> getContents().add(...) multiple times).
> Yes, although XMLResourceImpl doesn't like that while XMIResourceImpl
> doesn't mind (because it creates a "fake" XMI root element).
>> Removing an object doesn't always lead to an empty resource.
>> And even if I have an empty resource, I can discard it, since it is
>> empty...
> Yes, but what does saving the empty resource imply? A empty file isn't
> valid XML...
I would say there are two answers :
- An empty file isn't a valid XML, but an invalid resource XML can be
considered as an empty resource or no resource.
- Saving an empty resource could lead to the deletion of the resource
file (if any). That's what I wanted to say when telling that empty
resources can be discarded...
I imagine that XMLResourceImpl and XMIResourceImpl cannot manage empty
resources for good reasons. But I would also say that handling empty
resources is tied to the resource implementation. Maybe
"file-persisting" resources won't be able to handle it, but what about
other resource implementations ?
In my case, having an empty resource is not a problem...
>> I can't see the problem(s) here...
> That's because you haven't tried it all yet. :-P
I definitely need some practice on this topic...
But I still don't get why it's not possible to remove references to an
object which has no container.
What I was expecting of DeleteCommand when applied to any object (with
or without a container, and attached or not to a resource,) is to remove
all existing references to the object, and to recursively delete all
contained children object... This is not the case for objects that does
not have a container (or are contained by a resource). I still don't
understand. It doesn't even lead to an empty resource if the object is
not the resource's unique root...
Anyway, the only solution (-work around-) which allows to delete any
object is to always have a special root object in the resource which
contains all objects which don't have a (non special) container. And so
to always have the objects attached to a resource...
But this would be annoying to do it now :-(
>>
>> Note that I'm not used to XML issues since I use Resource objects that
>> delegates to an EStore (but I will have to handle XML in a few days...)
>>
>>>>
>>>> Thank you !
>>>> Stephane
>>>>
>> Thanks again !
|
|
|
| Re: DeleteCommand [message #425466 is a reply to message #425462] |
Wed, 26 November 2008 20:55 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Stephane,
Comments below.
SWT wrote:
> Ed,
>
> Comments below.
>
> Ed Merks wrote :
>> Stephane,
>>
>> Comments below.
>>
>> SWT wrote:
>>> Hi Ed,
>>>
>>> Comments below...
>>>
>>> Ed Merks wrote :
>>>> Stephane,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> SWT wrote:
>>>>> Hi!
>>>>>
>>>>> A DeleteCommand "removes an object from its parent container and
>>>>> deletes all other references to it from within the editing domain".
>>>>> But it seems that if the object is not contained by another model
>>>>> object, or if the object is contained by a resource object, the
>>>>> DeleteCommand becomes unexecutable because the RemoveCommand
>>>>> creation (which is meant to remove the object from it's container)
>>>>> returns an UnexecutableCommand.
>>>>>
>>>>> Is this really the expected behaviour of DeleteCommand ?
>>>> Yes, because we have no support for creating a new object in the
>>>> resource. Deleting one would leave you in a state where you could
>>>> not ever add one.
>>> I don't know if I understand well.
>>> Creating a new object in a resource is just something like :
>>> resource.getContents().add(FooFactory.eINSTANCE.createFoo()) ;
>>> If I delete the created "foo" object. There's nothing preventing me
>>> from adding another one later...
>>> I'm sure I'm missing something important here...
>> Indeed. But given that a resource can hold any type of object, this
>> would tend to imply that I can create an instance of any class of any
>> model.
> Yes. Is that a problem ?
Yes because imagine offering as a choice every class in every package
installed on the system. It's really not going to be useful to over
literally tens of thousands of choices when most of the choices are
highly unlikely produce desired results.
>
>> You'll notice that pop up menu in a resource doesn't by default allow
>> a child object to be created. Specializing your resource item
>> provider to support creation and deletion is certainly possible though
> Yes, this is kind of what I do in my app :
> I'm not using the resource item provider since my viewer's inputs are
> not resources, but I allow creation and deletion of objects.
That seems to beg the question of exactly what the user will click on to
create a new root object. Even if the inputs aren't resources, the
resources are still containers for the objects that are inputs.
> I can use my resource implementation to create a model object. In this
> case, the new object may be added to the resource's contents list.
> I can also create a model object with the generated EFactory. Then the
> object doesn't belong to any resource until it becomes referred by
> another object which belongs to a resource (then it is "attached" to
> the resource).
And how exactly will that happen.
>
>>>
>>>>> I thought that even if the object cannot be removed from a
>>>>> container, it still has to be de-referenced from other objects of
>>>>> the editing domain. Am I wrong ?
>>>>> If I am, then, should I create another command which does what I
>>>>> need, or is there something I'm missing ?
>>>> What will you do with the empty resource? It's not valid XML in
>>>> general to have no root object?
>>> There may be multiple root objects in a single resource (I can call
>>> getContents().add(...) multiple times).
>> Yes, although XMLResourceImpl doesn't like that while XMIResourceImpl
>> doesn't mind (because it creates a "fake" XMI root element).
>>> Removing an object doesn't always lead to an empty resource.
>>> And even if I have an empty resource, I can discard it, since it is
>>> empty...
>> Yes, but what does saving the empty resource imply? A empty file
>> isn't valid XML...
> I would say there are two answers :
> - An empty file isn't a valid XML, but an invalid resource XML can be
> considered as an empty resource or no resource.
Is that actually useful.
> - Saving an empty resource could lead to the deletion of the resource
> file (if any).
An empty file is not the same as an absent file and we already support
delete as a different concept.
> That's what I wanted to say when telling that empty resources can be
> discarded...
Well, you'll have to specialize things to get that behavior.
>
> I imagine that XMLResourceImpl and XMIResourceImpl cannot manage empty
> resources for good reasons.
XMIResourceImpl is okay, it just creates and empty fake XMI element to
make XML happy...
> But I would also say that handling empty resources is tied to the
> resource implementation.
Indeed that's true.
> Maybe "file-persisting" resources won't be able to handle it, but what
> about other resource implementations ?
XMIResourceImpl does XMLResourceImpl does not.
> In my case, having an empty resource is not a problem...
So you'll be able to do all the specialization you want in your context
where it all makes sense and where hopefully the ability to create new
objects in an empty resource will be supported in some way.
>
>>> I can't see the problem(s) here...
>> That's because you haven't tried it all yet. :-P
> I definitely need some practice on this topic...
> But I still don't get why it's not possible to remove references to an
> object which has no container.
Of course it's possible, it's just not supported for the reasons I
gave. Empty resources are not generally valid and there is no support
for populating a resource with a new object once it's empty because the
number of choices is too large to manage sensibly in a generic way.
> What I was expecting of DeleteCommand when applied to any object (with
> or without a container, and attached or not to a resource,) is to
> remove all existing references to the object, and to recursively
> delete all contained children object... This is not the case for
> objects that does not have a container (or are contained by a
> resource). I still don't understand. It doesn't even lead to an empty
> resource if the object is not the resource's unique root...
That's why it works in that case but not in the case where it's directly
contained by a resource. Of course you can specialize your
ResourceItemProvider to support remove, create child, add and anything
else you might want it to support.
>
> Anyway, the only solution (-work around-) which allows to delete any
> object is to always have a special root object in the resource which
> contains all objects which don't have a (non special) container. And
> so to always have the objects attached to a resource...
> But this would be annoying to do it now :-(
Specializing the item provider for the resource would accomplish the
same goal.
>
>>>
>>> Note that I'm not used to XML issues since I use Resource objects
>>> that delegates to an EStore (but I will have to handle XML in a few
>>> days...)
>>>
>>>>>
>>>>> Thank you !
>>>>> Stephane
>>>>>
>>> Thanks again !
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: DeleteCommand [message #425486 is a reply to message #425466] |
Thu, 27 November 2008 10:45 |
| Eclipse User |
|
|
|
Originally posted by: swt.magellium.fr
Ed,
Comments below.
Ed Merks wrote :
> Stephane,
>
> Comments below.
>
>
> SWT wrote:
>> Ed,
>>
>> Comments below.
>>
>> Ed Merks wrote :
>>> Stephane,
>>>
>>> Comments below.
>>>
>>> SWT wrote:
>>>> Hi Ed,
>>>>
>>>> Comments below...
>>>>
>>>> Ed Merks wrote :
>>>>> Stephane,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> SWT wrote:
>>>>>> Hi!
>>>>>>
>>>>>> A DeleteCommand "removes an object from its parent container and
>>>>>> deletes all other references to it from within the editing domain".
>>>>>> But it seems that if the object is not contained by another model
>>>>>> object, or if the object is contained by a resource object, the
>>>>>> DeleteCommand becomes unexecutable because the RemoveCommand
>>>>>> creation (which is meant to remove the object from it's container)
>>>>>> returns an UnexecutableCommand.
>>>>>>
>>>>>> Is this really the expected behaviour of DeleteCommand ?
>>>>> Yes, because we have no support for creating a new object in the
>>>>> resource. Deleting one would leave you in a state where you could
>>>>> not ever add one.
>>>> I don't know if I understand well.
>>>> Creating a new object in a resource is just something like :
>>>> resource.getContents().add(FooFactory.eINSTANCE.createFoo()) ;
>>>> If I delete the created "foo" object. There's nothing preventing me
>>>> from adding another one later...
>>>> I'm sure I'm missing something important here...
>>> Indeed. But given that a resource can hold any type of object, this
>>> would tend to imply that I can create an instance of any class of any
>>> model.
>> Yes. Is that a problem ?
> Yes because imagine offering as a choice every class in every package
> installed on the system. It's really not going to be useful to over
> literally tens of thousands of choices when most of the choices are
> highly unlikely produce desired results.
That is an UI concern... The resource can hold any object, but the
choice offered to the user may be restricted by UI code...
But you're true saying that this situation is imaginable...
>>
>>> You'll notice that pop up menu in a resource doesn't by default allow
>>> a child object to be created. Specializing your resource item
>>> provider to support creation and deletion is certainly possible though
>> Yes, this is kind of what I do in my app :
>> I'm not using the resource item provider since my viewer's inputs are
>> not resources, but I allow creation and deletion of objects.
> That seems to beg the question of exactly what the user will click on to
> create a new root object. Even if the inputs aren't resources, the
> resources are still containers for the objects that are inputs.
Yes, that's a problem. But still concerning the UI...
>> I can use my resource implementation to create a model object. In this
>> case, the new object may be added to the resource's contents list.
>> I can also create a model object with the generated EFactory. Then the
>> object doesn't belong to any resource until it becomes referred by
>> another object which belongs to a resource (then it is "attached" to
>> the resource).
> And how exactly will that happen.
Here is an example :
Foo foo = FooFactory.eINSTANCE.createFoo();
bar.setFoo(foo);
"foo" has no resource, no container, no related object...
"bar" belongs to a resource, which uses an EStore.
The setter delegates to the store.
Before setting the "foo" reference of the "bar" object in the store's
setter, I check if the "foo" object has an EStore.
In the current case, it has no store, so I set its store to be the
current one : the same as "bar".
During this process, all data contained in "foo"'s eSettings are copied
to the store's data so that "foo" can now ignore its eSettings and
delegate it's getters/setters to the store...
This works well since the notion of "attaching" to a resource means
"attaching" to the resource's store (because my resource implementation
delegates to its store...).
The case where "foo" and "bar" have different stores cannot happen in my
app because I have only one database which the store is based on. But it
may be imaginable to copy the objects. Then, there would be two versions
of the model objects, one for each store. That's quite dirty but that
can work...
>>
>>>>
>>>>>> I thought that even if the object cannot be removed from a
>>>>>> container, it still has to be de-referenced from other objects of
>>>>>> the editing domain. Am I wrong ?
>>>>>> If I am, then, should I create another command which does what I
>>>>>> need, or is there something I'm missing ?
>>>>> What will you do with the empty resource? It's not valid XML in
>>>>> general to have no root object?
>>>> There may be multiple root objects in a single resource (I can call
>>>> getContents().add(...) multiple times).
>>> Yes, although XMLResourceImpl doesn't like that while XMIResourceImpl
>>> doesn't mind (because it creates a "fake" XMI root element).
>>>> Removing an object doesn't always lead to an empty resource.
>>>> And even if I have an empty resource, I can discard it, since it is
>>>> empty...
>>> Yes, but what does saving the empty resource imply? A empty file
>>> isn't valid XML...
>> I would say there are two answers :
>> - An empty file isn't a valid XML, but an invalid resource XML can be
>> considered as an empty resource or no resource.
> Is that actually useful.
>> - Saving an empty resource could lead to the deletion of the resource
>> file (if any).
> An empty file is not the same as an absent file and we already support
> delete as a different concept.
Ok...
>> That's what I wanted to say when telling that empty resources can be
>> discarded...
> Well, you'll have to specialize things to get that behavior.
I wanted to make sure that specializing to get that behaviour will not
cause unexpected problems.
>>
>> I imagine that XMLResourceImpl and XMIResourceImpl cannot manage empty
>> resources for good reasons.
> XMIResourceImpl is okay, it just creates and empty fake XMI element to
> make XML happy...
>> But I would also say that handling empty resources is tied to the
>> resource implementation.
> Indeed that's true.
>> Maybe "file-persisting" resources won't be able to handle it, but what
>> about other resource implementations ?
> XMIResourceImpl does XMLResourceImpl does not.
>> In my case, having an empty resource is not a problem...
> So you'll be able to do all the specialization you want in your context
> where it all makes sense and where hopefully the ability to create new
> objects in an empty resource will be supported in some way.
Ok, so specializing things for my needs won't cause problems :-)
>>
>>>> I can't see the problem(s) here...
>>> That's because you haven't tried it all yet. :-P
>> I definitely need some practice on this topic...
>> But I still don't get why it's not possible to remove references to an
>> object which has no container.
> Of course it's possible, it's just not supported for the reasons I
> gave. Empty resources are not generally valid and there is no support
> for populating a resource with a new object once it's empty because the
> number of choices is too large to manage sensibly in a generic way.
Ok it's clear now :)
>> What I was expecting of DeleteCommand when applied to any object (with
>> or without a container, and attached or not to a resource,) is to
>> remove all existing references to the object, and to recursively
>> delete all contained children object... This is not the case for
>> objects that does not have a container (or are contained by a
>> resource). I still don't understand. It doesn't even lead to an empty
>> resource if the object is not the resource's unique root...
> That's why it works in that case but not in the case where it's directly
> contained by a resource. Of course you can specialize your
> ResourceItemProvider to support remove, create child, add and anything
> else you might want it to support.
Yep !
>>
>> Anyway, the only solution (-work around-) which allows to delete any
>> object is to always have a special root object in the resource which
>> contains all objects which don't have a (non special) container. And
>> so to always have the objects attached to a resource...
>> But this would be annoying to do it now :-(
> Specializing the item provider for the resource would accomplish the
> same goal.
Thank you again for your patience and clarity ! It's a great support !
>>
>>>>
>>>> Note that I'm not used to XML issues since I use Resource objects
>>>> that delegates to an EStore (but I will have to handle XML in a few
>>>> days...)
>>>>
>>>>>>
>>>>>> Thank you !
>>>>>> Stephane
>>>>>>
>>>> Thanks again !
PS : Sorry for the personal copy of the mail, I didn't want to spam your
personal mail box. I probably clicked "answer to all" by mistake last
time...
|
|
|
Goto Forum:
Current Time: Thu Apr 25 21:45:59 GMT 2024
Powered by FUDForum. Page generated in 0.03164 seconds |
] 
Search
Help
Register
Login
Home
