Home » Eclipse Projects » GEF » Commands
| Commands [message #74035] |
Tue, 01 April 2003 15:19  |
Eclipse User |
|
|
|
Originally posted by: melaasar.rational.com
Hello,
I have two questions about GEF's Command hierarchy:
1- Why did you switch from an interface to an abstract class? I always
thought having an interface is more flexible. In addition, this complicates
the adoption of a different command hierarchy or mixing commands from
different hierarchy (ex: EMF commands and GEF commands on the same command
stack). I always wished for a unified Command hierarchy across Eclipse.
2- GEF's instantiation of some commands like CompoundCommand in
editpolicies, actions, tools...etc is coming in the way of trying to extend
the command hierarchy to suit our needs. Since I don't control instantiating
these instances, those CompoundCommands cannot belong to my revised command
hierarchy. Any thoughts?
3- Was there a reason to take getResult() and getAffectedObjects() from the
class? I thought they are useful. Again, even if I added them in my own
override, I will hit the barrier mentioned in point 2.
Maged
|
|
|
| Re: Commands [message #74120 is a reply to message #74035] |
Wed, 02 April 2003 09:55  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> 1- Why did you switch from an interface to an abstract class? I always
> thought having an interface is more flexible. In addition, this
complicates
> the adoption of a different command hierarchy or mixing commands from
> different hierarchy (ex: EMF commands and GEF commands on the same command
> stack). I always wished for a unified Command hierarchy across Eclipse.
Some clients have asked for the ability to say why a Command is not
executable, for example: "Parent cannot contain more than five children",
and then maybe GEF would display this in the Status bar or something.
Adding new API to the interface would break existing code, but adding it to
a class would not.
> 2- GEF's instantiation of some commands like CompoundCommand in
> editpolicies, actions, tools...etc is coming in the way of trying to
extend
> the command hierarchy to suit our needs. Since I don't control
instantiating
> these instances, those CompoundCommands cannot belong to my revised
command
> hierarchy. Any thoughts?
>
> 3- Was there a reason to take getResult() and getAffectedObjects() from
the
> class? I thought they are useful. Again, even if I added them in my own
> override, I will hit the barrier mentioned in point 2.
In what way did you use these two methods? If I were using the Command API
to implement undo and redo in the Java Source Editor, what would these
methods mean? We were trying to reduce Command to only the methods that had
universal meaning, so that Eclipse base might accept them and there would be
a unified implementation. Obviously this didn't happen for 2.1, maybe 2.2.
|
|
|
| Re: Commands [message #74391 is a reply to message #74120] |
Thu, 03 April 2003 09:45 |
| Eclipse User |
|
|
|
Originally posted by: melaasar.rational.com
1- You can always provide the interface and still have a default
implementation that provides the default behavior. When you add a method to
the interface, you will also add it to the default implementation. Clients
who chose to subclass the default impl would get it for free. However,
others who wanted to implement the interface themselves (sometimes for good
reasons) would still get a chance. What do you think?
2- If you provided an interface for CompoundCommand and then used a method
like getNewCompoundCommand() that is overridable in every abstract artifact
where you use it (EditPolicy, EditorAction, Tool...etc) then again we can
override it to return our implementation of the interface to suit our
purpose.
3- I think getResult() was particularly usefull and generic enough. Some
commands like creation commands could return what was created. On the
minimum, we can choose to return a command status (success, failure..etc) as
the result.
4- Another useful method to have is one that returns the affected resources
in the command. You can always use that to identify the resources that needs
to be modifiable (writable, checked-out) for your command to execute
properly.
Maged
"Randy Hudson" <none@us.ibm.com> wrote in message
news:b6etbg$svi$1@rogue.oti.com...
> > 1- Why did you switch from an interface to an abstract class? I always
> > thought having an interface is more flexible. In addition, this
> complicates
> > the adoption of a different command hierarchy or mixing commands from
> > different hierarchy (ex: EMF commands and GEF commands on the same
command
> > stack). I always wished for a unified Command hierarchy across Eclipse.
>
> Some clients have asked for the ability to say why a Command is not
> executable, for example: "Parent cannot contain more than five children",
> and then maybe GEF would display this in the Status bar or something.
> Adding new API to the interface would break existing code, but adding it
to
> a class would not.
>
> > 2- GEF's instantiation of some commands like CompoundCommand in
> > editpolicies, actions, tools...etc is coming in the way of trying to
> extend
> > the command hierarchy to suit our needs. Since I don't control
> instantiating
> > these instances, those CompoundCommands cannot belong to my revised
> command
> > hierarchy. Any thoughts?
> >
> > 3- Was there a reason to take getResult() and getAffectedObjects() from
> the
> > class? I thought they are useful. Again, even if I added them in my own
> > override, I will hit the barrier mentioned in point 2.
>
> In what way did you use these two methods? If I were using the Command
API
> to implement undo and redo in the Java Source Editor, what would these
> methods mean? We were trying to reduce Command to only the methods that
had
> universal meaning, so that Eclipse base might accept them and there would
be
> a unified implementation. Obviously this didn't happen for 2.1, maybe
2.2.
>
>
>
|
|
|
| Re: Commands [message #74427 is a reply to message #74391] |
Thu, 03 April 2003 12:08 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Maged Elaasar" <melaasar@rational.com> wrote in message
news:b6hh0d$3jh$1@rogue.oti.com...
> 1- You can always provide the interface and still have a default
> implementation that provides the default behavior. When you add a method
to
> the interface, you will also add it to the default implementation. Clients
> who chose to subclass the default impl would get it for free. However,
> others who wanted to implement the interface themselves (sometimes for
good
> reasons) would still get a chance. What do you think?
I suppose we could have made Command an interface, and then marked it as
"this interface is not intended to be implemented by clients", which is the
standard comment that Eclipse uses if they want to be able to add methods
later, for example IAction.
> 2- If you provided an interface for CompoundCommand and then used a method
> like getNewCompoundCommand() that is overridable in every abstract
artifact
> where you use it (EditPolicy, EditorAction, Tool...etc) then again we can
> override it to return our implementation of the interface to suit our
> purpose.
Alternatively, if you need to do a tree traversal of you command structure
to union together the "affected objects" and the "result" of the commands,
you could do this in your CommandStack at the time of execution by wrapping
the top-level GEF command. For example:
class MyCommandStack extends CommandStack {
void execute(Command c){
ResultAndObjectWrapperCommand wrap;
wrap = new ResultAndObjectWrapperCommand(c);
super.execute(c);
}
}
class ResultAndObjectWrapperCommand extends Command {
Collection result;
Collection affected;
Command delegate;
void execute() {
delegate.execute();
result = extractResultFrom(delegate);
affected = extractAffectedFrom(delegate);
}
Collection extractResultFrom(Command branch) {
//recurse test
//perform a test to see if branch is a CompoundCommand, if so,
recusively extract
// its children results
//perform test to see if branch implements getResult() interface, if so,
union its result
}
....similar for affected objects, undo, redo if necessary
}
> 3- I think getResult() was particularly usefull and generic enough. Some
> commands like creation commands could return what was created. On the
> minimum, we can choose to return a command status (success, failure..etc)
as
> the result.
Maybe too generic.
This was not the intended use of getResult(). getResult() is used in a copy
operation (in EMF) to clone the object being copied. The fact that you are
using getResult() to mean something else is an indication that its intended
use is not common, therefore why have the method?
In a closed application you could reuse such a method to mean anything you
want. But if your editor is pluggable and others will be contributing
commands (maybe EditPolicies/EditParts), everyone has to agree.
> 4- Another useful method to have is one that returns the affected
resources
> in the command. You can always use that to identify the resources that
needs
> to be modifiable (writable, checked-out) for your command to execute
> properly.
getAffectedObjects() is used to determine which objects should be selected
in a viewer after the command is executed. So, if you create a new "class"
object, select the class afterwards.
|
|
|
Goto Forum:
Current Time: Fri Jul 25 23:24:06 EDT 2025
Powered by FUDForum. Page generated in 0.04649 seconds |
Home