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

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Paul, thanks for broadcasting this on
the e4 list.  Its a really good discussion.

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

I agree that global commands having
to juggle active handlers is the root of many problems.  Its confusing,
its prone to bugs, it  raises performance questions, and it locks
us in artificially. 

At a high level what I'm hearing is:

Command: the abstract, singleton, fixed-state
notion of work to be performed (e.g. save)
Handler: the concrete _expression_ of
performing the work in context (e.g. save the editor's contents)
Context: the concrete _expression_ of
the workbench state, in a hierarchy which matches the parts (and widgets),
providing access to current UI state (e.g. the actual text to be saved).

This arrangement is going to be critical
to allow multiple workbenches and multiple users, and to simplify the job
of writing commands.  This work is very important and we all need
to be looking at it more closely.  I will shamefully admit to only
(finally!) reading the wiki page today.

Kevin

"Paul Webster" <pwebster@xxxxxxxxxxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

07/28/2008 01:20 PM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	"E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject	[eclipse-incubator-e4-dev] Re: news.eclipse.platform.rcp: Command        handlers and multiple workbench windows

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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev