Eclipse Community Forums: EMF » ItemproviderAdapter#factorRemoveCommand

Help

Home

Home » Modeling » EMF » ItemproviderAdapter#factorRemoveCommand

Show: Today's Messages :: Show Polls :: Message Navigator

ItemproviderAdapter#factorRemoveCommand [message #417258]

Tue, 04 March 2008 03:15

Jasper
Messages: 84
Registered: July 2009

Member

EMF 2.3.2, ItemProviderAdapter.java:1205-1215

// If all the objects are used up by the above, then we can't do the
command.
//
if (list.isEmpty())
{
return removeCommand.unwrap();
}
else
{
removeCommand.dispose();
return UnexecutableCommand.INSTANCE;
}

Looks like the removeCommand gets disposed when it's _not_ empty, and
unwrapped when it's empty, which comes down to return
UnexecutableCommand.INSTANCE in both cases.

Am I missing something, or is this a bug?

Thanks,
Jasper.

Report message to a moderator

Re: ItemproviderAdapter#factorRemoveCommand [message #417265 is a reply to message #417258]

Tue, 04 March 2008 06:23

Ed Merks
Messages: 25227
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------090402090602080104070806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jasper,

It should really say "aren't" used up, but the logic itself is correct.
Unwrapping the compound command will do the following, so if the final
result is not executable, it's because the commands that were created
aren't executable (or because no command were created at all).

| /**
* Returns one of three things:
* {@link org.eclipse.emf.common.command.UnexecutableCommand#INSTANCE} , if there are no commands,
* the one command, if there is exactly one command,
* or <code>this</code>, if there are multiple commands;
* this command is {@link #dispose}d in the first two cases.
* You should only unwrap a compound command if you created it for that purpose, e.g.,
* <pre>
* CompoundCommand subcommands = new CompoundCommand();
* subcommands.append(x);
* if (condition) subcommands.append(y);
* Command result = subcommands.unwrap();
* </pre>
* is a good way to create an efficient accumulated result.
* @return the unwrapped command.
*/
*public *Command unwrap()
{
*switch *(commandList.size())
{
*case *0:
{
dispose();
*return *UnexecutableCommand.INSTANCE;
}
*case *1:
{
Command result = commandList.remove(0);
dispose();
*return *result;
}
*default*:
{
*return this*;
}
}
}|

Jasper wrote:
> EMF 2.3.2, ItemProviderAdapter.java:1205-1215
>
> // If all the objects are used up by the above, then we can't do the
> command.
> //
> if (list.isEmpty())
> {
> return removeCommand.unwrap();
> }
> else
> {
> removeCommand.dispose();
> return UnexecutableCommand.INSTANCE;
> }
>
> Looks like the removeCommand gets disposed when it's _not_ empty, and
> unwrapped when it's empty, which comes down to return
> UnexecutableCommand.INSTANCE in both cases.
>
> Am I missing something, or is this a bug?
>
> Thanks,
> Jasper.

--------------090402090602080104070806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jasper, 
 
It should really say "aren't" used up, but the logic itself is
correct.  Unwrapping the compound command will do the following, so if
the final result is not executable, it's because the commands that were
created aren't executable (or because no command were created at all). 
<blockquote>
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">


<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code>  /** 
    * Returns one of three&a mp;nbsp;things:  
   *  {@link org.eclipse.emf.common.command.UnexecutableC ommand#INSTANCE} , if there are no&nb sp;commands, 
    * the one command, if&am p;nbsp;there is exactly one&n bsp;command, 
   * or <code>this</code> , if there are multiple& amp;nbsp;commands; 
   * this command is  {@link #dispose} d in the first two&n bsp;cases. 
    * You should only unwrap  a compound command if&a mp;nbsp;you created it for&nb sp;that purpose, e.g., 
   * <pre> 
    *   CompoundCommand subc ommands = new CompoundCommand(); 
   *   subcommands.append(x); 
    *   if (condition)&n bsp;subcommands.append(y); 
    *   Command result&n bsp;= subcommands.unwrap(); 
   * </pre> 
    * is a good way&nbsp ;to create an efficient  accumulated result. 
   * @return the unwrapped command. 
   */ 
  public Command unwrap() 
  { 
    switch (commandList.size()) 
    { 
        case 0: 
        { 
           dispose(); 
           return UnexecutableCommand.INSTANCE; 
        } 
        case 1: 
        { 
           Command result = commandList.remo ve (0); 
           dispose(); 
           return result; 
        } 
        default: 
        { 
           return this; 
        } 
    } 
  }</code>
</td>
 </tr>
</tbody>
</table>
</div>

</blockquote>
 
 
Jasper wrote:
<blockquote cite="mid:fqj0eo$fg4$1@build.eclipse.org" type="cite">EMF
2.3.2, ItemProviderAdapter.java:1205-1215
 
 
// If all the objects are used up by the above, then we can't do the
command.
 
//
 
if (list.isEmpty())
 
{
 
  return removeCommand.unwrap();
 
}
 
else
 
{
 
  removeCommand.dispose();
 
  return UnexecutableCommand.INSTANCE;
 
}
 
 
Looks like the removeCommand gets disposed when it's _not_ empty, and
unwrapped when it's empty, which comes down to return
UnexecutableCommand.INSTANCE in both cases.
 
 
Am I missing something, or is this a bug?
 
 
Thanks,
 
Jasper.
 
</blockquote>
 
</body>
</html>

--------------090402090602080104070806--

Report message to a moderator

Re: ItemproviderAdapter#factorRemoveCommand [message #417269 is a reply to message #417265]

Tue, 04 March 2008 08:06

Jasper
Messages: 84
Registered: July 2009

Member

You sure get up early Ed! (Assuming you're in Toronto..)

From your response I understand that the bug is in the comment ;-)
Still, when I try to remove a top-level EObject from a Resource, this
code doesn't work for me. I've debugged through and to be honest I lose
the plot a bit when the compound command gets constructed, apparently to
deal with children of the node that's about to be removed (which, for
the sake of simplicity I have ensured it doesn't have). Final result
(for me) is that my top-level EObject is still on the "list" used in
#factorRemoveCommand and so it gets disposed and the command returned is
the UnexecutableCommand.

What am I doing wrong?

Ed Merks wrote:
> Jasper,
>
> It should really say "aren't" used up, but the logic itself is correct.
> Unwrapping the compound command will do the following, so if the final
> result is not executable, it's because the commands that were created
> aren't executable (or because no command were created at all).
>
> | /**
> * Returns one of three things:
> * {@link org.eclipse.emf.common.command.UnexecutableCommand#INSTANCE} , if there are no commands,
> * the one command, if there is exactly one command,
> * or <code>this</code>, if there are multiple commands;
> * this command is {@link #dispose}d in the first two cases.
> * You should only unwrap a compound command if you created it for that purpose, e.g.,
> * <pre>
> * CompoundCommand subcommands = new CompoundCommand();
> * subcommands.append(x);
> * if (condition) subcommands.append(y);
> * Command result = subcommands.unwrap();
> * </pre>
> * is a good way to create an efficient accumulated result.
> * @return the unwrapped command.
> */
> *public *Command unwrap()
> {
> *switch *(commandList.size())
> {
> *case *0:
> {
> dispose();
> *return *UnexecutableCommand.INSTANCE;
> }
> *case *1:
> {
> Command result = commandList.remove(0);
> dispose();
> *return *result;
> }
> *default*:
> {
> *return this*;
> }
> }
> }|
>
>
>
> Jasper wrote:
>> EMF 2.3.2, ItemProviderAdapter.java:1205-1215
>>
>> // If all the objects are used up by the above, then we can't do the
>> command.
>> //
>> if (list.isEmpty())
>> {
>> return removeCommand.unwrap();
>> }
>> else
>> {
>> removeCommand.dispose();
>> return UnexecutableCommand.INSTANCE;
>> }
>>
>> Looks like the removeCommand gets disposed when it's _not_ empty, and
>> unwrapped when it's empty, which comes down to return
>> UnexecutableCommand.INSTANCE in both cases.
>>
>> Am I missing something, or is this a bug?
>>
>> Thanks,
>> Jasper.
>

Report message to a moderator

Re: ItemproviderAdapter#factorRemoveCommand [message #417271 is a reply to message #417269]

Tue, 04 March 2008 08:27

Ed Merks
Messages: 25227
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------010508010203080808000909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jasper,

Comments below.

Jasper wrote:
> You sure get up early Ed! (Assuming you're in Toronto..)
Yes, I am in Toronto and I do tend to get up rather early.
>
> From your response I understand that the bug is in the comment ;-)
Yep. :-P
> Still, when I try to remove a top-level EObject from a Resource, this
> code doesn't work for me.
I wouldn't expect it to get here for this case since the resource isn't
an EObject.
> I've debugged through and to be honest I lose the plot a bit when the
> compound command gets constructed, apparently to deal with children of
> the node that's about to be removed (which, for the sake of simplicity
> I have ensured it doesn't have).
The eObject should be the owner (parent) of the object being removed and
that code is trying to figure out which feature the object is being
removed from. To remove an object from its resource, you'd create a
command like this, where list is Resource.getContents().

| /**
* This constructs a primitive command to remove a particular value from the specified extent.
*/
*public *RemoveCommand(EditingDomain domain, EList<?> list, Object value)
{
*this*(domain, list, Collections.singleton(value));
}|

> Final result (for me) is that my top-level EObject is still on the
> "list" used in #factorRemoveCommand and so it gets disposed and the
> command returned is the UnexecutableCommand.
>
> What am I doing wrong?
Probably that you're trying to use a command for removing an object from
an EObject parent when there isn't one...
>
>
> Ed Merks wrote:
>> Jasper,
>>
>> It should really say "aren't" used up, but the logic itself is
>> correct. Unwrapping the compound command will do the following, so
>> if the final result is not executable, it's because the commands that
>> were created aren't executable (or because no command were created at
>> all).
>>
>> | /**
>> * Returns one of three things: * {@link
>> org.eclipse.emf.common.command.UnexecutableCommand#INSTANCE} , if
>> there are no commands,
>> * the one command, if there is exactly one command,
>> * or <code>this</code>, if there are multiple commands;
>> * this command is {@link #dispose}d in the first two cases.
>> * You should only unwrap a compound command if you created it
>> for that purpose, e.g.,
>> * <pre>
>> * CompoundCommand subcommands = new CompoundCommand();
>> * subcommands.append(x);
>> * if (condition) subcommands.append(y);
>> * Command result = subcommands.unwrap();
>> * </pre>
>> * is a good way to create an efficient accumulated result.
>> * @return the unwrapped command.
>> */
>> *public *Command unwrap()
>> {
>> *switch *(commandList.size())
>> {
>> *case *0:
>> {
>> dispose();
>> *return *UnexecutableCommand.INSTANCE;
>> }
>> *case *1:
>> {
>> Command result = commandList.remove(0);
>> dispose();
>> *return *result;
>> }
>> *default*:
>> {
>> *return this*;
>> }
>> }
>> }|
>>
>>
>>
>> Jasper wrote:
>>> EMF 2.3.2, ItemProviderAdapter.java:1205-1215
>>>
>>> // If all the objects are used up by the above, then we can't do the
>>> command.
>>> //
>>> if (list.isEmpty())
>>> {
>>> return removeCommand.unwrap();
>>> }
>>> else
>>> {
>>> removeCommand.dispose();
>>> return UnexecutableCommand.INSTANCE;
>>> }
>>>
>>> Looks like the removeCommand gets disposed when it's _not_ empty,
>>> and unwrapped when it's empty, which comes down to return
>>> UnexecutableCommand.INSTANCE in both cases.
>>>
>>> Am I missing something, or is this a bug?
>>>
>>> Thanks,
>>> Jasper.
>>

--------------010508010203080808000909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jasper, 
 
Comments below. 
 
Jasper wrote:
<blockquote cite="mid:47CD496A.9090503@yahoo.com" type="cite">You sure
get up early Ed! (Assuming you're in Toronto..)
 
</blockquote>
Yes, I am in Toronto and I do tend to get up rather early. 
<blockquote cite="mid:47CD496A.9090503@yahoo.com" type="cite"> 
From your response I understand that the bug is in the comment ;-)</blockquote>
Yep.  :-P 
<blockquote cite="mid:47CD496A.9090503@yahoo.com" type="cite"> Still,
when I try to remove a top-level EObject from a Resource, this code
doesn't work for me.</blockquote>
I wouldn't expect it to get here for this case since the resource isn't
an EObject. 
<blockquote cite="mid:47CD496A.9090503@yahoo.com" type="cite"> I've
debugged through and to be honest I lose the plot a bit when the
compound command gets constructed, apparently to deal with children of
the node that's about to be removed (which, for the sake of simplicity
I have ensured it doesn't have). </blockquote>
The eObject should be the owner (parent) of the object being removed
and that code is trying to figure out which feature the object is being
removed from. To remove an object from its resource, you'd create a
command like this, where list is Resource.getContents(). 
<blockquote>
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">


<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code>  /** 
    * This constructs a prim itive command to remove  a particular value from  the specified extent. 
   */ 
  public RemoveCommand( EditingDomain domain, EList<?&g t; list, Object value )  
  { 
    this(domain, list, Collections.singleton (value)); 
  }</code>
</td>
 </tr>
</tbody>
</table>
</div>

</blockquote>
<blockquote cite="mid:47CD496A.9090503@yahoo.com" type="cite">Final
result (for me) is that my top-level EObject is still on the "list"
used in #factorRemoveCommand and so it gets disposed and the command
returned is the UnexecutableCommand.
 
 
What am I doing wrong?
 
</blockquote>
Probably that you're trying to use a command for removing an object
from an EObject parent when there isn't one... 
<blockquote cite="mid:47CD496A.9090503@yahoo.com" type="cite"> 
 
Ed Merks wrote:
 
<blockquote type="cite">Jasper,
 
 
It should really say "aren't" used up, but the logic itself is
correct.  Unwrapping the compound command will do the following, so if
the final result is not executable, it's because the commands that were
created aren't executable (or because no command were created at all).
 
 
    |  /**
 
       * Returns one of three things:        * {@link
org.eclipse.emf.common.command.UnexecutableCommand#INSTANCE} , if there
are no commands,
 
       * the one command, if there is exactly one command,
 
       * or <code>this</code>, if there are multiple
commands;
 
       * this command is {@link #dispose}d in the first two cases.
 
       * You should only unwrap a compound command if you created it
for that purpose, e.g.,
 
       * <pre>
 
       *   CompoundCommand subcommands = new CompoundCommand();
 
       *   subcommands.append(x);
 
       *   if (condition) subcommands.append(y);
 
       *   Command result = subcommands.unwrap();
 
       * </pre>
 
       * is a good way to create an efficient accumulated result.
 
       * @return the unwrapped command.
 
       */
 
      *public *Command unwrap()
 
      {
 
         *switch *(commandList.size())
 
         {
 
           *case *0:
 
           {
 
             dispose();
 
             *return *UnexecutableCommand.INSTANCE;
 
           }
 
           *case *1:
 
           {
 
             Command result = commandList.remove(0);
 
             dispose();
 
             *return *result;
 
           }
 
           *default*:
 
           {
 
             *return this*;
 
           }
 
         }
 
      }|
 
 
 
 
Jasper wrote:
 
<blockquote type="cite">EMF 2.3.2,
ItemProviderAdapter.java:1205-1215
 
 
// If all the objects are used up by the above, then we can't do the
command.
 
//
 
if (list.isEmpty())
 
{
 
  return removeCommand.unwrap();
 
}
 
else
 
{
 
  removeCommand.dispose();
 
  return UnexecutableCommand.INSTANCE;
 
}
 
 
Looks like the removeCommand gets disposed when it's _not_ empty, and
unwrapped when it's empty, which comes down to return
UnexecutableCommand.INSTANCE in both cases.
 
 
Am I missing something, or is this a bug?
 
 
Thanks,
 
Jasper.
 
</blockquote>
 
</blockquote>
</blockquote>
 
</body>
</html>

--------------010508010203080808000909--

Report message to a moderator

Re: ItemproviderAdapter#factorRemoveCommand [message #417311 is a reply to message #417271]

Wed, 05 March 2008 01:10

Jasper
Messages: 84
Registered: July 2009

Member

<SNIP>
> To remove an object from its resource, you'd create a
> command like this, where list is Resource.getContents().
>
> /**
* This constructs a primitive command to remove a particular
value from the specified extent.
*/
> public RemoveCommand(EditingDomain domain, EList<?> list, Object value)
> {
> this(domain, list, Collections.singleton(value));
> }

Yep this made it work.

>> Final result (for me) is that my top-level EObject is still on the
>> "list" used in #factorRemoveCommand and so it gets disposed and the
>> command returned is the UnexecutableCommand.
>>
>> What am I doing wrong?
> Probably that you're trying to use a command for removing an object from
> an EObject parent when there isn't one...

I was using RemoveCommand.createCommand(EditingDomain,Object) to create
the Command. So I guess this factory method only works when the Object
has an EObject parent. Perhaps there should be mention of this in the
API docs, or an exception to this effect?

Thanks,
Jasper.

Report message to a moderator

Re: ItemproviderAdapter#factorRemoveCommand [message #417318 is a reply to message #417311]

Wed, 05 March 2008 06:25

Ed Merks
Messages: 25227
Registered: July 2009

Senior Member

Jasper,

If you follow all the delegation steps, you'll see that ultimately the
resource item provider decides if it will support remove and while the
default one doesn't, it can be specialized to allow that, but also would
beg for an action to create a new child, since an empty resource becomes
useless. So we can't really say at the starting point, the static
Remove.create method, that something specifically isn't going to work.
In addition, commands are not designed to fail with an exception simply
because they can't execute. They're designed to indicate via their
canExecute method whether the desired action can be carried out.

Jasper wrote:
> <SNIP>
>> To remove an object from its resource, you'd create a command like
>> this, where list is Resource.getContents().
>>
>> /**
> * This constructs a primitive command to remove a particular
> value from the specified extent.
> */
>> public RemoveCommand(EditingDomain domain, EList<?> list,
>> Object value)
>> {
>> this(domain, list, Collections.singleton(value));
>> }
>
> Yep this made it work.
>
>>> Final result (for me) is that my top-level EObject is still on the
>>> "list" used in #factorRemoveCommand and so it gets disposed and the
>>> command returned is the UnexecutableCommand.
>>>
>>> What am I doing wrong?
>> Probably that you're trying to use a command for removing an object
>> from an EObject parent when there isn't one...
>
> I was using RemoveCommand.createCommand(EditingDomain,Object) to
> create the Command. So I guess this factory method only works when the
> Object has an EObject parent. Perhaps there should be mention of this
> in the API docs, or an exception to this effect?
>
> Thanks,
> Jasper.

Report message to a moderator

Previous Topic:	Type cast error in generated code
Next Topic:	Default values for Attributes not Serialized

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Oct 08 08:03:32 EDT 2013