Mike Parker <[EMAIL PROTECTED]> 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 _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
