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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
