[eclipse-incubator-e4-dev] Re: news.eclipse.platform.rcp: Command handle

["Paul Webster" <pwebster@xxxxxxxxxxxxxxxxxxx>]

Mike Parker <mhparker@xxxxxxxxxx>  responded:

Paul Webster wrote:
> Some investigation seems to indicate that we need to activate, enabled, and execute our handlers all within the same context.  That way the print icon in one workbench window would be asking isEnabled(context) within its window context, and would not be effected by a different workbench window context.
>
>
> Check out http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00356.html
>
> We're investigating a number of aspects of this problem in the 4.0 stream.
>

Paul,

Many thanks for the answer and link.

I don't know whether this is the right place to discuss design stuff
on this topic, so I'll try to make this answer as short as possible.

The page (http://wiki.eclipse.org/E4/Commands) referenced indirectly
by the URL you provided hints strongly at using localized handlers
rather than (as I originally suggested) multiply instantiated
commands. That makes some sense, because commands have several
properties (e.g., description, ID, etc.) that are inherently global in
nature.

However, using singleton commands in conjunction with multiple
localized handlers still begs the question as to how a command can be
bound to multiple localized handlers simultaneously. Storing and
maintaining a list of bound handlers for each global command,
including making sure the local handlers are removed from the list
when their associated context is no longer available, does not sound
like a very satisfying experience to me!

Therefore, I'm wondering whether we need another layer between
commands and handlers, namely something like a "command binding"
object. These command binding objects would provide the "glue" between
the handlers and the corresponding global command. They would be
lightweight objects that contain a reference to the command, a
listener list, and possibly not much else. These command bindings
could be largely transparent to the applications. For example, if the
"scope" of a command would be (via new XML syntax) defined as being
local to a part with a given ID, then the command binding would be
internally instantiated (and stored with) each instance of that part.
Furthermore, when an object (such as a command contribution item)
attempts to reference a command, the corresponding (local or global)
context would be searched for an existing binding for that command. If
none is found, a new one would dynamically be instantiated. Any
command listeners set by the application would actually be set for the
binding instead (in general, only the command bindings would set
listeners on the commands themselves). Updating the UI would then
involve refreshing the single installed handler for each local command
binding for each command, each handler receiving its binding's context
as input (e.g., the "context" argument in the isEnabled(context)
invocation you mention).

Maybe you and others have already been thinking along similar lines?
If not, perhaps the above ideas could be added to the melting pot for
E4? I hope so, and also hope that any further changes to the PCF are
(from an external API point-of-view) incremental, rather than radical.

Thanks in advance.

Cheers,
Mike



-- 
Paul Webster
Hi floor. Make me a sammich! - GIR