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

["Paul Webster" <pwebster@xxxxxxxxxxxxxxxxxxx>]

Mike Parker wrote:
> 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.

Right ... experience seems to indicate that the command should have
"meta" information.  ID, name, description, maybe some parameter type
information if that needs to be supported.


> 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!

Using commands for meta-information does imply that they won't know
anything about their handlers ... the flow of information cannot go
that way (it does now, and causes a wide variety of exciting
problems).

>
> Therefore, I'm wondering whether we need another layer between commands
> and handlers, namely something like a "command binding" object.

The pattern we're investigating is definitely heading in this kind of
direction.  For one, there's no such thing as a command listener any
more (no asynchronous event state to post).  When a UI element needs
to 1) find if the "command" is enabled or 2) execute the "command"
they can go to their local context (a locator object).  The specific
pattern hasn't been decided on, but asking the locator for the
IHandlerService and then requesting info for the command ID or
executing that ID would perform much the same as a "binding object"
... the IHandlerService+"the specific locator" is responsible for
looking up the appropriate handler.   It never goes near the global
command meta-object.

That way a local UI element will always talk to its local handler.
The IHandlerService is the intermediary that can load/instantiate
local handlers (based on XML syntax that allows handler to be mapped
to specific levels or parts or through programmatic activation).  The
local context/locator provides a place to store any local bindings,
and also strategies for looking up any information that is not local
to that context.

This conversation has been useful to me, and I've taken the liberty of
re-posting it to the E4 mailing list to make sure others that are
thinking of this problem are aware.  Thanx, Mike.

> 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.

And that is the problem :-)  PCF was introduced because the Action API
was written in such a way as to preclude this evolution.  PCF is
written with this notion of 1) global singleton command that can only
have one handler active and 2) global singleton command state.  There
will have to be a level of compatibility (we can't abandon any API
willy-nilly) but any code going through the singleton command will at
best be limited to the current behaviour.  Only adopting the new 4.0
pattern will allow the more complex "local UI element" scenarios to be
supported.  Maybe :-)  With no implementation and only a few
investigation prototypes we haven't reached the point where we can
preclude any of the API.

Later,
PW


-- 
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/workbench.htm