Home » Modeling » EMF » Emf.Edit: Deletion of a linkage instead of the linked element itself
| Emf.Edit: Deletion of a linkage instead of the linked element itself [message #547755] |
Mon, 19 July 2010 14:24  |
 Stefan Jurack
Messages: 24
Registered: February 2010 |
Junior Member |
|
|
Hi,
if class A is contained by B and additionally referred to by C, this is
reflected in the standard tree-editor by the capability of
drag'n'droping A-objects from their containment position (below
B-objects) to another position (below C-objects) creating the additional
linkage. If I delete an A-object from its position below C, I would
suggest the linkage to be removed only, instead the element is deleted
from the whole model i.e. particularly from its containment!?
Debugging brought to light that when selecting an element in the
tree-editor, method 'DeleteAction.updateSelection' calls
'DeleteCommand.create(domain, selection)'. Triggering the deletion
(pressing del-key) executes this command, removing each element (purely)
listed in 'selection' from its containment. Afterwards, the "correct"
RemoveCommand of the appropriate C-itemprovider is executed, of course
without any effect.
Is this intended behavior and is there a convenient way to change the
behavior to my suggested one?
Thanks in advance,
Stefan
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #547756 is a reply to message #547755] |
Mon, 19 July 2010 14:30  |
Stefan Jurack
Messages: 24
Registered: February 2010 |
Junior Member |
|
|
Me again,
right after writing this, I found that:
http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
I will check that first.
Thnx
Am 19.07.2010 16:24, schrieb Stefan Jurack:
> Hi,
>
> if class A is contained by B and additionally referred to by C, this is
> reflected in the standard tree-editor by the capability of
> drag'n'droping A-objects from their containment position (below
> B-objects) to another position (below C-objects) creating the additional
> linkage. If I delete an A-object from its position below C, I would
> suggest the linkage to be removed only, instead the element is deleted
> from the whole model i.e. particularly from its containment!?
>
> Debugging brought to light that when selecting an element in the
> tree-editor, method 'DeleteAction.updateSelection' calls
> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
> (pressing del-key) executes this command, removing each element (purely)
> listed in 'selection' from its containment. Afterwards, the "correct"
> RemoveCommand of the appropriate C-itemprovider is executed, of course
> without any effect.
>
> Is this intended behavior and is there a convenient way to change the
> behavior to my suggested one?
>
> Thanks in advance,
> Stefan
>
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #547855 is a reply to message #547756] |
Mon, 19 July 2010 20:26 |
Stefan Jurack
Messages: 24
Registered: February 2010 |
Junior Member |
|
|
Hi,
after investigating in the thread (and the referred one) below, further
references and code, I got stuck again.
I changed method "isWrappingNeeded" of my non-model itemprovider to
return true, and so far, the wrapper is created correctly. But when
createCommand of my itemprovider is called, in fact the one of class
ItemProviderAdapter, method unwrapCommandValues discards the feature
setting within the DelegatingWrapperItemProvider, which is important for
deletion.
So, what did I miss? Do I have to override the createCommand method and
set the feature manually? But otherwise, for multiple-selections this
may not fit.
Regards,
Stefan
Am 19.07.2010 16:30, schrieb Stefan Jurack:
> Me again,
>
> right after writing this, I found that:
>
> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
>
> I will check that first.
>
> Thnx
>
> Am 19.07.2010 16:24, schrieb Stefan Jurack:
>> Hi,
>>
>> if class A is contained by B and additionally referred to by C, this is
>> reflected in the standard tree-editor by the capability of
>> drag'n'droping A-objects from their containment position (below
>> B-objects) to another position (below C-objects) creating the additional
>> linkage. If I delete an A-object from its position below C, I would
>> suggest the linkage to be removed only, instead the element is deleted
>> from the whole model i.e. particularly from its containment!?
>>
>> Debugging brought to light that when selecting an element in the
>> tree-editor, method 'DeleteAction.updateSelection' calls
>> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
>> (pressing del-key) executes this command, removing each element (purely)
>> listed in 'selection' from its containment. Afterwards, the "correct"
>> RemoveCommand of the appropriate C-itemprovider is executed, of course
>> without any effect.
>>
>> Is this intended behavior and is there a convenient way to change the
>> behavior to my suggested one?
>>
>> Thanks in advance,
>> Stefan
>>
>
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548031 is a reply to message #547855] |
Tue, 20 July 2010 13:06 |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080708010503020005050001
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Stefan,
This logic in DeleteCommand.execute should delete all references to the
object only if it becomes a dangling reference:
for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>>
entry : usages.entrySet())
{
EObject eObject = entry.getKey();
*if (eObject.eResource() == null)*
{
So I'm not sure what problem you're seeing.
Regards,
Ed
Stefan Jurack wrote:
> Hi,
>
> after investigating in the thread (and the referred one) below, further
> references and code, I got stuck again.
> I changed method "isWrappingNeeded" of my non-model itemprovider to
> return true, and so far, the wrapper is created correctly. But when
> createCommand of my itemprovider is called, in fact the one of class
> ItemProviderAdapter, method unwrapCommandValues discards the feature
> setting within the DelegatingWrapperItemProvider, which is important for
> deletion.
>
> So, what did I miss? Do I have to override the createCommand method and
> set the feature manually? But otherwise, for multiple-selections this
> may not fit.
>
> Regards,
> Stefan
>
>
> Am 19.07.2010 16:30, schrieb Stefan Jurack:
>
>> Me again,
>>
>> right after writing this, I found that:
>>
>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
>>
>> I will check that first.
>>
>> Thnx
>>
>> Am 19.07.2010 16:24, schrieb Stefan Jurack:
>>
>>> Hi,
>>>
>>> if class A is contained by B and additionally referred to by C, this is
>>> reflected in the standard tree-editor by the capability of
>>> drag'n'droping A-objects from their containment position (below
>>> B-objects) to another position (below C-objects) creating the additional
>>> linkage. If I delete an A-object from its position below C, I would
>>> suggest the linkage to be removed only, instead the element is deleted
>>> from the whole model i.e. particularly from its containment!?
>>>
>>> Debugging brought to light that when selecting an element in the
>>> tree-editor, method 'DeleteAction.updateSelection' calls
>>> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
>>> (pressing del-key) executes this command, removing each element (purely)
>>> listed in 'selection' from its containment. Afterwards, the "correct"
>>> RemoveCommand of the appropriate C-itemprovider is executed, of course
>>> without any effect.
>>>
>>> Is this intended behavior and is there a convenient way to change the
>>> behavior to my suggested one?
>>>
>>> Thanks in advance,
>>> Stefan
>>>
>>>
>
>
--------------080708010503020005050001
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
This logic in DeleteCommand.execute should delete all references to the
object only if it becomes a dangling reference:<br>
<br>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548035 is a reply to message #548031] |
Tue, 20 July 2010 13:42 |
Stefan Jurack
Messages: 24
Registered: February 2010 |
Junior Member |
|
|
Hi Ed,
I missed to tell, that I set method 'removeAllReferencesOnDelete()' in
my xxActionBarContributor to return false (as recommended by you in the
discussion
http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0058.html).
When I did both steps, setting 'removeAllReferencesOnDelete' to return
'false' and 'isWrappingNeeded' to return 'true', the wrappers for my
linked entities are created correctly. Trying to deletion them in the
tree-based editor, however, leads to the deletion of the contained
element anyway instead of the wrapper. Imo, this is due to the fact,
that in ItemProviderAdapter... :
public Command createCommand(Object object, EditingDomain domain,
Class<? extends Command> commandClass, CommandParameter commandParameter)
{
CommandParameter oldCommandParameter = commandParameter;
commandParameter = unwrapCommandValues(commandParameter, commandClass);
.... method 'unwrapCommandValues' discards any feature information
contained in the wrapper. Thus, it's not clear anymore which feature to
use for deletion... :
else if (commandClass == RemoveCommand.class)
{
if (commandParameter.getEStructuralFeature() != null)
{
result = createRemoveCommand(domain,
commandParameter.getEOwner(), commandParameter.getEStructuralFeature(),
commandParameter.getCollection());
}
else
{
result = factorRemoveCommand(domain, commandParameter);
}
}
.... leading to a call to 'factorRemoveCommand'. Here, any feature is
choosen for removal if the wrapped element is contained in.
I hope this made it clear?!
Regards,
Stefan
Am 20.07.2010 15:06, schrieb Ed Merks:
> Stefan,
>
> This logic in DeleteCommand.execute should delete all references to the
> object only if it becomes a dangling reference:
>
> for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>>
> entry : usages.entrySet())
> {
> EObject eObject = entry.getKey();
> *if (eObject.eResource() == null)*
> {
>
> So I'm not sure what problem you're seeing.
>
> Regards,
> Ed
>
>
> Stefan Jurack wrote:
>> Hi,
>>
>> after investigating in the thread (and the referred one) below, further
>> references and code, I got stuck again.
>> I changed method "isWrappingNeeded" of my non-model itemprovider to
>> return true, and so far, the wrapper is created correctly. But when
>> createCommand of my itemprovider is called, in fact the one of class
>> ItemProviderAdapter, method unwrapCommandValues discards the feature
>> setting within the DelegatingWrapperItemProvider, which is important for
>> deletion.
>>
>> So, what did I miss? Do I have to override the createCommand method and
>> set the feature manually? But otherwise, for multiple-selections this
>> may not fit.
>>
>> Regards,
>> Stefan
>>
>>
>> Am 19.07.2010 16:30, schrieb Stefan Jurack:
>>
>>> Me again,
>>>
>>> right after writing this, I found that:
>>>
>>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
>>>
>>> I will check that first.
>>>
>>> Thnx
>>>
>>> Am 19.07.2010 16:24, schrieb Stefan Jurack:
>>>
>>>> Hi,
>>>>
>>>> if class A is contained by B and additionally referred to by C, this is
>>>> reflected in the standard tree-editor by the capability of
>>>> drag'n'droping A-objects from their containment position (below
>>>> B-objects) to another position (below C-objects) creating the additional
>>>> linkage. If I delete an A-object from its position below C, I would
>>>> suggest the linkage to be removed only, instead the element is deleted
>>>> from the whole model i.e. particularly from its containment!?
>>>>
>>>> Debugging brought to light that when selecting an element in the
>>>> tree-editor, method 'DeleteAction.updateSelection' calls
>>>> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
>>>> (pressing del-key) executes this command, removing each element (purely)
>>>> listed in 'selection' from its containment. Afterwards, the "correct"
>>>> RemoveCommand of the appropriate C-itemprovider is executed, of course
>>>> without any effect.
>>>>
>>>> Is this intended behavior and is there a convenient way to change the
>>>> behavior to my suggested one?
>>>>
>>>> Thanks in advance,
>>>> Stefan
>>>>
>>>>
>>
>>
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548070 is a reply to message #548035] |
Tue, 20 July 2010 14:58 |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010800080704090600050000
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Stefan,
Try not setting removeAllReferencesOnDelete to false. In general, you
really do need to make sure that all references to a deleted object are
removed, otherwise saving will throw dangling reference exception. Once
you do that, pay close attention to what's happening in
DeleteCommand.execute. It should clean up all references to a deleted
object, but only if that object is no longer contained by a resource.
So for the case you describe, the object should only be removed from its
parent. More comments below.
Stefan Jurack wrote:
> Hi Ed,
>
> I missed to tell, that I set method 'removeAllReferencesOnDelete()' in
> my xxActionBarContributor to return false (as recommended by you in the
> discussion
> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0058.html).
>
> When I did both steps, setting 'removeAllReferencesOnDelete' to return
> 'false' and 'isWrappingNeeded' to return 'true', the wrappers for my
> linked entities are created correctly. Trying to deletion them in the
> tree-based editor, however, leads to the deletion of the contained
> element anyway instead of the wrapper. Imo, this is due to the fact,
> that in ItemProviderAdapter... :
>
> public Command createCommand(Object object, EditingDomain domain,
> Class<? extends Command> commandClass, CommandParameter commandParameter)
> {
>
> CommandParameter oldCommandParameter = commandParameter;
> commandParameter = unwrapCommandValues(commandParameter, commandClass);
>
>
> ... method 'unwrapCommandValues' discards any feature information
> contained in the wrapper.
Doesn't it keep the feature?
if (newCollection != null || newValue != oldValue)
{
commandParameter = new CommandParameter(
commandParameter.owner,
*commandParameter.feature,*
newValue,
newCollection,
commandParameter.index);
}
> Thus, it's not clear anymore which feature to
> use for deletion... :
>
> else if (commandClass == RemoveCommand.class)
> {
> if (commandParameter.getEStructuralFeature() != null)
> {
> result = createRemoveCommand(domain,
> commandParameter.getEOwner(), commandParameter.getEStructuralFeature(),
> commandParameter.getCollection());
> }
> else
> {
> result = factorRemoveCommand(domain, commandParameter);
> }
> }
>
> ... leading to a call to 'factorRemoveCommand'. Here, any feature is
> choosen for removal if the wrapped element is contained in.
>
All children features are considered. Does the same parent both
reference and contain this "child"?
> I hope this made it clear?!
>
> Regards,
> Stefan
>
>
>
>
> Am 20.07.2010 15:06, schrieb Ed Merks:
>
>> Stefan,
>>
>> This logic in DeleteCommand.execute should delete all references to the
>> object only if it becomes a dangling reference:
>>
>> for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>>
>> entry : usages.entrySet())
>> {
>> EObject eObject = entry.getKey();
>> *if (eObject.eResource() == null)*
>> {
>>
>> So I'm not sure what problem you're seeing.
>>
>> Regards,
>> Ed
>>
>>
>> Stefan Jurack wrote:
>>
>>> Hi,
>>>
>>> after investigating in the thread (and the referred one) below, further
>>> references and code, I got stuck again.
>>> I changed method "isWrappingNeeded" of my non-model itemprovider to
>>> return true, and so far, the wrapper is created correctly. But when
>>> createCommand of my itemprovider is called, in fact the one of class
>>> ItemProviderAdapter, method unwrapCommandValues discards the feature
>>> setting within the DelegatingWrapperItemProvider, which is important for
>>> deletion.
>>>
>>> So, what did I miss? Do I have to override the createCommand method and
>>> set the feature manually? But otherwise, for multiple-selections this
>>> may not fit.
>>>
>>> Regards,
>>> Stefan
>>>
>>>
>>> Am 19.07.2010 16:30, schrieb Stefan Jurack:
>>>
>>>
>>>> Me again,
>>>>
>>>> right after writing this, I found that:
>>>>
>>>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
>>>>
>>>> I will check that first.
>>>>
>>>> Thnx
>>>>
>>>> Am 19.07.2010 16:24, schrieb Stefan Jurack:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> if class A is contained by B and additionally referred to by C, this is
>>>>> reflected in the standard tree-editor by the capability of
>>>>> drag'n'droping A-objects from their containment position (below
>>>>> B-objects) to another position (below C-objects) creating the additional
>>>>> linkage. If I delete an A-object from its position below C, I would
>>>>> suggest the linkage to be removed only, instead the element is deleted
>>>>> from the whole model i.e. particularly from its containment!?
>>>>>
>>>>> Debugging brought to light that when selecting an element in the
>>>>> tree-editor, method 'DeleteAction.updateSelection' calls
>>>>> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
>>>>> (pressing del-key) executes this command, removing each element (purely)
>>>>> listed in 'selection' from its containment. Afterwards, the "correct"
>>>>> RemoveCommand of the appropriate C-itemprovider is executed, of course
>>>>> without any effect.
>>>>>
>>>>> Is this intended behavior and is there a convenient way to change the
>>>>> behavior to my suggested one?
>>>>>
>>>>> Thanks in advance,
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
--------------010800080704090600050000
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
Try not setting removeAllReferencesOnDelete to false.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548084 is a reply to message #548070] |
Tue, 20 July 2010 15:30 |
Stefan Jurack
Messages: 24
Registered: February 2010 |
Junior Member |
|
|
Hi Ed,
See comments below.
Am 20.07.2010 16:58, schrieb Ed Merks:
> Stefan,
>
> Try not setting removeAllReferencesOnDelete to false. In general, you
> really do need to make sure that all references to a deleted object are
> removed, otherwise saving will throw dangling reference exception. Once
> you do that, pay close attention to what's happening in
> DeleteCommand.execute. It should clean up all references to a deleted
> object, but only if that object is no longer contained by a resource.
> So for the case you describe, the object should only be removed from its
> parent.
Ok.
More comments below.
>
> Stefan Jurack wrote:
>> Hi Ed,
>>
>> I missed to tell, that I set method 'removeAllReferencesOnDelete()' in
>> my xxActionBarContributor to return false (as recommended by you in the
>> discussion
>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0058.html).
>>
>> When I did both steps, setting 'removeAllReferencesOnDelete' to return
>> 'false' and 'isWrappingNeeded' to return 'true', the wrappers for my
>> linked entities are created correctly. Trying to deletion them in the
>> tree-based editor, however, leads to the deletion of the contained
>> element anyway instead of the wrapper. Imo, this is due to the fact,
>> that in ItemProviderAdapter... :
>>
>> public Command createCommand(Object object, EditingDomain domain,
>> Class<? extends Command> commandClass, CommandParameter commandParameter)
>> {
>>
>> CommandParameter oldCommandParameter = commandParameter;
>> commandParameter = unwrapCommandValues(commandParameter, commandClass);
>>
>>
>> ... method 'unwrapCommandValues' discards any feature information
>> contained in the wrapper.
> Doesn't it keep the feature?
>
> if (newCollection != null || newValue != oldValue)
> {
> commandParameter = new CommandParameter(
> commandParameter.owner,
> *commandParameter.feature,*
> newValue,
> newCollection,
> commandParameter.index);
> }
The problem here is, that commandParameter.feature is alway null. In
contrast, the wrapper object contains the required feature, but it is
never used in any way. Consider the following in DeleteAction... :
public Command createCommand(Collection<?> selection)
{
return removeAllReferences ? *DeleteCommand.create(domain,
selection)* : RemoveCommand.create(domain, selection);
}
.... which leads to... :
public static Command create(EditingDomain domain, final Collection<?>
collection)
{
return domain.createCommand(DeleteCommand.class, new
*CommandParameter(null, null, collection)*);
}
.... Here, the feature in CommandParameter is explicitly set to null,
while collection contains the wrapper class with its feature information
embedded.
Regards, Stefan
>> Thus, it's not clear anymore which feature to
>> use for deletion... :
>>
>> else if (commandClass == RemoveCommand.class)
>> {
>> if (commandParameter.getEStructuralFeature() != null)
>> {
>> result = createRemoveCommand(domain,
>> commandParameter.getEOwner(), commandParameter.getEStructuralFeature(),
>> commandParameter.getCollection());
>> }
>> else
>> {
>> result = factorRemoveCommand(domain, commandParameter);
>> }
>> }
>>
>> ... leading to a call to 'factorRemoveCommand'. Here, any feature is
>> choosen for removal if the wrapped element is contained in.
>>
> All children features are considered. Does the same parent both
> reference and contain this "child"?
>> I hope this made it clear?!
>>
>> Regards,
>> Stefan
>>
>>
>>
>>
>> Am 20.07.2010 15:06, schrieb Ed Merks:
>>
>>> Stefan,
>>>
>>> This logic in DeleteCommand.execute should delete all references to the
>>> object only if it becomes a dangling reference:
>>>
>>> for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>>
>>> entry : usages.entrySet())
>>> {
>>> EObject eObject = entry.getKey();
>>> *if (eObject.eResource() == null)*
>>> {
>>>
>>> So I'm not sure what problem you're seeing.
>>>
>>> Regards,
>>> Ed
>>>
>>>
>>> Stefan Jurack wrote:
>>>
>>>> Hi,
>>>>
>>>> after investigating in the thread (and the referred one) below, further
>>>> references and code, I got stuck again.
>>>> I changed method "isWrappingNeeded" of my non-model itemprovider to
>>>> return true, and so far, the wrapper is created correctly. But when
>>>> createCommand of my itemprovider is called, in fact the one of class
>>>> ItemProviderAdapter, method unwrapCommandValues discards the feature
>>>> setting within the DelegatingWrapperItemProvider, which is important for
>>>> deletion.
>>>>
>>>> So, what did I miss? Do I have to override the createCommand method and
>>>> set the feature manually? But otherwise, for multiple-selections this
>>>> may not fit.
>>>>
>>>> Regards,
>>>> Stefan
>>>>
>>>>
>>>> Am 19.07.2010 16:30, schrieb Stefan Jurack:
>>>>
>>>>
>>>>> Me again,
>>>>>
>>>>> right after writing this, I found that:
>>>>>
>>>>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
>>>>>
>>>>> I will check that first.
>>>>>
>>>>> Thnx
>>>>>
>>>>> Am 19.07.2010 16:24, schrieb Stefan Jurack:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> if class A is contained by B and additionally referred to by C, this is
>>>>>> reflected in the standard tree-editor by the capability of
>>>>>> drag'n'droping A-objects from their containment position (below
>>>>>> B-objects) to another position (below C-objects) creating the additional
>>>>>> linkage. If I delete an A-object from its position below C, I would
>>>>>> suggest the linkage to be removed only, instead the element is deleted
>>>>>> from the whole model i.e. particularly from its containment!?
>>>>>>
>>>>>> Debugging brought to light that when selecting an element in the
>>>>>> tree-editor, method 'DeleteAction.updateSelection' calls
>>>>>> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
>>>>>> (pressing del-key) executes this command, removing each element (purely)
>>>>>> listed in 'selection' from its containment. Afterwards, the "correct"
>>>>>> RemoveCommand of the appropriate C-itemprovider is executed, of course
>>>>>> without any effect.
>>>>>>
>>>>>> Is this intended behavior and is there a convenient way to change the
>>>>>> behavior to my suggested one?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Stefan
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548091 is a reply to message #548084] |
Tue, 20 July 2010 15:51 |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080302080201060607040908
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Stefan,
Comments below.
Stefan Jurack wrote:
> Hi Ed,
>
> See comments below.
>
>
> Am 20.07.2010 16:58, schrieb Ed Merks:
>
>> Stefan,
>>
>> Try not setting removeAllReferencesOnDelete to false. In general, you
>> really do need to make sure that all references to a deleted object are
>> removed, otherwise saving will throw dangling reference exception. Once
>> you do that, pay close attention to what's happening in
>> DeleteCommand.execute. It should clean up all references to a deleted
>> object, but only if that object is no longer contained by a resource.
>> So for the case you describe, the object should only be removed from its
>> parent.
>>
>
> Ok.
>
> More comments below.
>
>> Stefan Jurack wrote:
>>
>>> Hi Ed,
>>>
>>> I missed to tell, that I set method 'removeAllReferencesOnDelete()' in
>>> my xxActionBarContributor to return false (as recommended by you in the
>>> discussion
>>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0058.html).
>>>
>>> When I did both steps, setting 'removeAllReferencesOnDelete' to return
>>> 'false' and 'isWrappingNeeded' to return 'true', the wrappers for my
>>> linked entities are created correctly. Trying to deletion them in the
>>> tree-based editor, however, leads to the deletion of the contained
>>> element anyway instead of the wrapper. Imo, this is due to the fact,
>>> that in ItemProviderAdapter... :
>>>
>>> public Command createCommand(Object object, EditingDomain domain,
>>> Class<? extends Command> commandClass, CommandParameter commandParameter)
>>> {
>>>
>>> CommandParameter oldCommandParameter = commandParameter;
>>> commandParameter = unwrapCommandValues(commandParameter, commandClass);
>>>
>>>
>>> ... method 'unwrapCommandValues' discards any feature information
>>> contained in the wrapper.
>>>
>> Doesn't it keep the feature?
>>
>> if (newCollection != null || newValue != oldValue)
>> {
>> commandParameter = new CommandParameter(
>> commandParameter.owner,
>> *commandParameter.feature,*
>> newValue,
>> newCollection,
>> commandParameter.index);
>> }
>>
>
> The problem here is, that commandParameter.feature is alway null.
That's a different issue from what you said about it being discarded...
> In
> contrast, the wrapper object contains the required feature, but it is
> never used in any way. Consider the following in DeleteAction... :
>
> public Command createCommand(Collection<?> selection)
> {
> return removeAllReferences ? *DeleteCommand.create(domain,
> selection)* : RemoveCommand.create(domain, selection);
> }
>
>
> ... which leads to... :
>
> public static Command create(EditingDomain domain, final Collection<?>
> collection)
> {
> return domain.createCommand(DeleteCommand.class, new
> *CommandParameter(null, null, collection)*);
> }
>
> ... Here, the feature in CommandParameter is explicitly set to null,
> while collection contains the wrapper class with its feature information
> embedded.
>
There is no command parameter yet at this point. There's only a
selection for the things that need to be deleted.
So where does this leave things? You're claiming that all references to
the object are being removed? I've directed you to look at what's
happening in DeleteCommand. I would expect that only a single
RemoveCommand is being created and I would expect that to remove the
object from its non-containment reference. What's actually happening?
>
> Regards, Stefan
>
>
>
>>> Thus, it's not clear anymore which feature to
>>> use for deletion... :
>>>
>>> else if (commandClass == RemoveCommand.class)
>>> {
>>> if (commandParameter.getEStructuralFeature() != null)
>>> {
>>> result = createRemoveCommand(domain,
>>> commandParameter.getEOwner(), commandParameter.getEStructuralFeature(),
>>> commandParameter.getCollection());
>>> }
>>> else
>>> {
>>> result = factorRemoveCommand(domain, commandParameter);
>>> }
>>> }
>>>
>>> ... leading to a call to 'factorRemoveCommand'. Here, any feature is
>>> choosen for removal if the wrapped element is contained in.
>>>
>>>
>> All children features are considered. Does the same parent both
>> reference and contain this "child"?
>>
>>> I hope this made it clear?!
>>>
>>> Regards,
>>> Stefan
>>>
>>>
>>>
>>>
>>> Am 20.07.2010 15:06, schrieb Ed Merks:
>>>
>>>
>>>> Stefan,
>>>>
>>>> This logic in DeleteCommand.execute should delete all references to the
>>>> object only if it becomes a dangling reference:
>>>>
>>>> for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>>
>>>> entry : usages.entrySet())
>>>> {
>>>> EObject eObject = entry.getKey();
>>>> *if (eObject.eResource() == null)*
>>>> {
>>>>
>>>> So I'm not sure what problem you're seeing.
>>>>
>>>> Regards,
>>>> Ed
>>>>
>>>>
>>>> Stefan Jurack wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> after investigating in the thread (and the referred one) below, further
>>>>> references and code, I got stuck again.
>>>>> I changed method "isWrappingNeeded" of my non-model itemprovider to
>>>>> return true, and so far, the wrapper is created correctly. But when
>>>>> createCommand of my itemprovider is called, in fact the one of class
>>>>> ItemProviderAdapter, method unwrapCommandValues discards the feature
>>>>> setting within the DelegatingWrapperItemProvider, which is important for
>>>>> deletion.
>>>>>
>>>>> So, what did I miss? Do I have to override the createCommand method and
>>>>> set the feature manually? But otherwise, for multiple-selections this
>>>>> may not fit.
>>>>>
>>>>> Regards,
>>>>> Stefan
>>>>>
>>>>>
>>>>> Am 19.07.2010 16:30, schrieb Stefan Jurack:
>>>>>
>>>>>
>>>>>
>>>>>> Me again,
>>>>>>
>>>>>> right after writing this, I found that:
>>>>>>
>>>>>> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0250.html
>>>>>>
>>>>>> I will check that first.
>>>>>>
>>>>>> Thnx
>>>>>>
>>>>>> Am 19.07.2010 16:24, schrieb Stefan Jurack:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> if class A is contained by B and additionally referred to by C, this is
>>>>>>> reflected in the standard tree-editor by the capability of
>>>>>>> drag'n'droping A-objects from their containment position (below
>>>>>>> B-objects) to another position (below C-objects) creating the additional
>>>>>>> linkage. If I delete an A-object from its position below C, I would
>>>>>>> suggest the linkage to be removed only, instead the element is deleted
>>>>>>> from the whole model i.e. particularly from its containment!?
>>>>>>>
>>>>>>> Debugging brought to light that when selecting an element in the
>>>>>>> tree-editor, method 'DeleteAction.updateSelection' calls
>>>>>>> 'DeleteCommand.create(domain, selection)'. Triggering the deletion
>>>>>>> (pressing del-key) executes this command, removing each element (purely)
>>>>>>> listed in 'selection' from its containment. Afterwards, the "correct"
>>>>>>> RemoveCommand of the appropriate C-itemprovider is executed, of course
>>>>>>> without any effect.
>>>>>>>
>>>>>>> Is this intended behavior and is there a convenient way to change the
>>>>>>> behavior to my suggested one?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Stefan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
--------------080302080201060607040908
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
Comments below.<br>
<br>
Stefan Jurack wrote:
<blockquote cite="mid:i24ff2$5dm$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
See comments below.
Am 20.07.2010 16:58, schrieb Ed Merks:
</pre>
<blockquote type="cite">
<pre wrap="">Stefan,
Try not setting removeAllReferencesOnDelete to false. In general, you
really do need to make sure that all references to a deleted object are
removed, otherwise saving will throw dangling reference exception. Once
you do that, pay close attention to what's happening in
DeleteCommand.execute. It should clean up all references to a deleted
object, but only if that object is no longer contained by a resource.
So for the case you describe, the object should only be removed from its
parent.
</pre>
</blockquote>
<pre wrap=""><!---->
Ok.
More comments below.
</pre>
<blockquote type="cite">
<pre wrap="">Stefan Jurack wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Ed,
I missed to tell, that I set method 'removeAllReferencesOnDelete()' in
my xxActionBarContributor to return false (as recommended by you in the
discussion
<a class="moz-txt-link-freetext" href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0058.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg3 0058.html</a>).
When I did both steps, setting 'removeAllReferencesOnDelete' to return
'false' and 'isWrappingNeeded' to return 'true', the wrappers for my
linked entities are created correctly. Trying to deletion them in the
tree-based editor, however, leads to the deletion of the contained
element anyway instead of the wrapper. Imo, this is due to the fact,
that in ItemProviderAdapter... :
public Command createCommand(Object object, EditingDomain domain,
Class<? extends Command> commandClass, CommandParameter commandParameter)
{
CommandParameter oldCommandParameter = commandParameter;
commandParameter = unwrapCommandValues(commandParameter, commandClass);
.... method 'unwrapCommandValues' discards any feature information
contained in the wrapper.
</pre>
</blockquote>
<pre wrap="">Doesn't it keep the feature?
if (newCollection != null || newValue != oldValue)
{
commandParameter = new CommandParameter(
commandParameter.owner,
*commandParameter.feature,*
newValue,
newCollection,
commandParameter.index);
}
</pre>
</blockquote>
<pre wrap=""><!---->
The problem here is, that commandParameter.feature is alway null. </pre>
</blockquote>
That's a different issue from what you said about it being discarded...<br>
<blockquote cite="mid:i24ff2$5dm$1@build.eclipse.org" type="cite">
<pre wrap="">In
contrast, the wrapper object contains the required feature, but it is
never used in any way. Consider the following in DeleteAction... :
public Command createCommand(Collection<?> selection)
{
return removeAllReferences ? *DeleteCommand.create(domain,
selection)* : RemoveCommand.create(domain, selection);
}
.... which leads to... :
public static Command create(EditingDomain domain, final Collection<?>
collection)
{
return domain.createCommand(DeleteCommand.class, new
*CommandParameter(null, null, collection)*);
}
.... Here, the feature in CommandParameter is explicitly set to null,
while collection contains the wrapper class with its feature information
embedded.
</pre>
</blockquote>
There is no command parameter yet at this point.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548149 is a reply to message #548091] |
Tue, 20 July 2010 19:14 |
Stefan Jurack
Messages: 24
Registered: February 2010 |
Junior Member |
|
|
Ed,
hope you don't mind, I've cleaned this post a bit up.
Am 20.07.2010 17:51, schrieb Ed Merks:
>>
>> The problem here is, that commandParameter.feature is alway null.
> That's a different issue from what you said about it being discarded...
Hmm, may be the following fits better: The feature contained in the
wrapper is not taken into account.
Am 20.07.2010 17:51, schrieb Ed Merks:
>>
>> In
>> contrast, the wrapper object contains the required feature, but it is
>> never used in any way. Consider the following in DeleteAction... :
>>
>> public Command createCommand(Collection<?> selection)
>> {
>> return removeAllReferences ? *DeleteCommand.create(domain,
>> selection)* : RemoveCommand.create(domain, selection);
>> }
>>
>>
>> ... which leads to... :
>>
>> public static Command create(EditingDomain domain, final Collection<?>
>> collection)
>> {
>> return domain.createCommand(DeleteCommand.class, new
>> *CommandParameter(null, null, collection)*);
>> }
>>
>> ... Here, the feature in CommandParameter is explicitly set to null,
>> while collection contains the wrapper class with its feature information
>> embedded.
>>
> There is no command parameter yet at this point. There's only a
> selection for the things that need to be deleted.
I marked the newly created CommandParameter with its feature set to
null. If you mean that this is not the command parameter used in the
resulting RemoveCommand, you're right. I only showed this to indicate
that feature is unset from the beginning.
>
> So where does this leave things? You're claiming that all references to
> the object are being removed? I've directed you to look at what's
> happening in DeleteCommand. I would expect that only a single
> RemoveCommand is being created and I would expect that to remove the
> object from its non-containment reference. What's actually happening?
You're right again, only one RemoveCommand is created. This is
something, that has been misinterpreted by me due to a refresh problem.
Nevertheless, the problem occurs anyway in a slightly different shape!
Consider the following:
Class A is contained by B, while C has two (or more) ordinary references
ca1 and ca2 targeting class A. In the tree-editor I distinguish between
ca1 and ca2 by introducing two non-model items. If I delete an object :A
in ca1, which is referred to by ca1 *and* ca2, this leads to confusions
by the algorithm due to method ItemProviderAdapter.factorRemoveCommand
which looks for any(!) feature of :C to contain :A. This is exactly what
happens in my case. The wrong feature is chosen and thus deleted.
Instead of looking for any feature, the feature given within the wrapper
could have been taken into account directly.
Regards,
Stefan
|
|
|
| Re: Emf.Edit: Deletion of a linkage instead of the linked element itself [message #548164 is a reply to message #548149] |
Tue, 20 July 2010 21:30 |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090500010903040601050702
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Stefan,
So as I suspected, the problem is with factor remove command not being
able to disambiguate... You'll need to specialize your item provider's
createCommand to deal better with this kind of unusual case, taking into
account the extra information provided by the IWrapperItemProvider
around the child.
Stefan Jurack wrote:
> Ed,
>
> hope you don't mind, I've cleaned this post a bit up.
>
> Am 20.07.2010 17:51, schrieb Ed Merks:
>
>>> The problem here is, that commandParameter.feature is alway null.
>>>
>> That's a different issue from what you said about it being discarded...
>>
>
> Hmm, may be the following fits better: The feature contained in the
> wrapper is not taken into account.
>
> Am 20.07.2010 17:51, schrieb Ed Merks:
>
>>> In
>>> contrast, the wrapper object contains the required feature, but it is
>>> never used in any way. Consider the following in DeleteAction... :
>>>
>>> public Command createCommand(Collection<?> selection)
>>> {
>>> return removeAllReferences ? *DeleteCommand.create(domain,
>>> selection)* : RemoveCommand.create(domain, selection);
>>> }
>>>
>>>
>>> ... which leads to... :
>>>
>>> public static Command create(EditingDomain domain, final Collection<?>
>>> collection)
>>> {
>>> return domain.createCommand(DeleteCommand.class, new
>>> *CommandParameter(null, null, collection)*);
>>> }
>>>
>>> ... Here, the feature in CommandParameter is explicitly set to null,
>>> while collection contains the wrapper class with its feature information
>>> embedded.
>>>
>>>
>> There is no command parameter yet at this point. There's only a
>> selection for the things that need to be deleted.
>>
>
> I marked the newly created CommandParameter with its feature set to
> null. If you mean that this is not the command parameter used in the
> resulting RemoveCommand, you're right. I only showed this to indicate
> that feature is unset from the beginning.
>
>
>> So where does this leave things? You're claiming that all references to
>> the object are being removed? I've directed you to look at what's
>> happening in DeleteCommand. I would expect that only a single
>> RemoveCommand is being created and I would expect that to remove the
>> object from its non-containment reference. What's actually happening?
>>
>
> You're right again, only one RemoveCommand is created. This is
> something, that has been misinterpreted by me due to a refresh problem.
> Nevertheless, the problem occurs anyway in a slightly different shape!
> Consider the following:
> Class A is contained by B, while C has two (or more) ordinary references
> ca1 and ca2 targeting class A. In the tree-editor I distinguish between
> ca1 and ca2 by introducing two non-model items. If I delete an object :A
> in ca1, which is referred to by ca1 *and* ca2, this leads to confusions
> by the algorithm due to method ItemProviderAdapter.factorRemoveCommand
> which looks for any(!) feature of :C to contain :A. This is exactly what
> happens in my case. The wrong feature is chosen and thus deleted.
> Instead of looking for any feature, the feature given within the wrapper
> could have been taken into account directly.
>
> Regards,
> Stefan
>
--------------090500010903040601050702
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
So as I suspected, the problem is with factor remove command not being
able to disambiguate... You'll need to specialize your item provider's
createCommand to deal better with this kind of unusual case, taking
into account the extra information provided by the IWrapperItemProvider
around the child.<br>
<br>
<br>
Stefan Jurack wrote:
<blockquote cite="mid:i24sj2$kkn$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,
hope you don't mind, I've cleaned this post a bit up.
Am 20.07.2010 17:51, schrieb Ed Merks:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The problem here is, that commandParameter.feature is alway null.
</pre>
</blockquote>
<pre wrap="">That's a different issue from what you said about it being discarded...
</pre>
</blockquote>
<pre wrap=""><!---->
Hmm, may be the following fits better: The feature contained in the
wrapper is not taken into account.
Am 20.07.2010 17:51, schrieb Ed Merks:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">In
contrast, the wrapper object contains the required feature, but it is
never used in any way. Consider the following in DeleteAction... :
public Command createCommand(Collection<?> selection)
{
return removeAllReferences ? *DeleteCommand.create(domain,
selection)* : RemoveCommand.create(domain, selection);
}
.... which leads to... :
public static Command create(EditingDomain domain, final Collection<?>
collection)
{
return domain.createCommand(DeleteCommand.class, new
*CommandParameter(null, null, collection)*);
}
.... Here, the feature in CommandParameter is explicitly set to null,
while collection contains the wrapper class with its feature information
embedded.
</pre>
</blockquote>
<pre wrap="">There is no command parameter yet at this point. There's only a
selection for the things that need to be deleted.
</pre>
</blockquote>
<pre wrap=""><!---->
I marked the newly created CommandParameter with its feature set to
null. If you mean that this is not the command parameter used in the
resulting RemoveCommand, you're right. I only showed this to indicate
that feature is unset from the beginning.
</pre>
<blockquote type="cite">
<pre wrap="">So where does this leave things? You're claiming that all references to
the object are being removed? I've directed you to look at what's
happening in DeleteCommand. I would expect that only a single
RemoveCommand is being created and I would expect that to remove the
object from its non-containment reference. What's actually happening?
</pre>
</blockquote>
<pre wrap=""><!---->
You're right again, only one RemoveCommand is created. This is
something, that has been misinterpreted by me due to a refresh problem.
Nevertheless, the problem occurs anyway in a slightly different shape!
Consider the following:
Class A is contained by B, while C has two (or more) ordinary references
ca1 and ca2 targeting class A. In the tree-editor I distinguish between
ca1 and ca2 by introducing two non-model items. If I delete an object :A
in ca1, which is referred to by ca1 *and* ca2, this leads to confusions
by the algorithm due to method ItemProviderAdapter.factorRemoveCommand
which looks for any(!) feature of :C to contain :A. This is exactly what
happens in my case. The wrong feature is chosen and thus deleted.
Instead of looking for any feature, the feature given within the wrapper
could have been taken into account directly.
Regards,
Stefan
</pre>
</blockquote>
</body>
</html>
--------------090500010903040601050702--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue May 07 18:57:36 GMT 2024
Powered by FUDForum. Page generated in 0.03361 seconds |
] 
Search
Help
Register
Login
Home
