Re: [platform-ui-dev] Canadian Idol - or - follow your role-model: Conte

[Randy Hudson <hudsonr@xxxxxxxxxx>]

I had a previous question about what
was meant by Command.  A "Command" is a class of actions
that are all similar.  A command is basically the descriptorID that
identifies an action, and causes it to inherit the keybinding associated
with that Command.

Don't get this concept confused with
the "real" command pattern, used for undo and redo.

-Randy

Chris Laffra <Chris_Laffra@xxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 09/11/2003 09:37 AM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-ui-dev] Canadian Idol - or - follow your role-model: Contexts, Commands, Actions

With interest, I read the Context proposal at

       http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/contexts/contexts.html

I have some questions/remarks.

1. Why the digression in layout style. Where is the familiar (boring) 
Eclipse header? 

2. The proposal makes excellent points on Command vs. Actions, and
made me think of Intentional Programming. Contexts are suggested as
a solution and an extension point in org.eclipse.ui is proposed. Fine.

3. The article does consider hierarchies of contexts, see "parentId".
However, the poor sole who has to define the hierarchy of 
contexts for even something as small as Eclipse itself - I pitty him/her.
I think contexts are context-free (how's that for a cool meta-statement).
In other words, a context is not bound to a parent, but a parent defines
what contexts it manages. This modification generates a sort of
multiple inheritance hierarchy (multiple contexts can claim a given
context as child and promote/demote them). From the ground up,
the implementation for Contexts should have excellent 
introspection, tracing and debugging capabilities. Just image the
newsgroups: "Why doesn't my Print button show?", "Does one
of 
the gazillion plugins perhaps promote the "Printer Toner Low"
context? 
We should promote that the hierarchy of Contexts stays
shallow. No deep, redundant hierarchies, please. 

4. I propose to add the concept of "Role" - a metalevel Context.
Many discussions I have seen in this area describe users of 
Eclipse playing different "roles" (architect, developer, tester,
manager, etc). If the userr role is made explicit (in the UI) menu 
options that appear/disappear would not surprise the user as much.

5. Contexts will be abused for controlling the entire UI. Someone
will add a nifty small extension and make them Turing complete.
All hell will break loose then. Spaghetti code written in XML.
People will use Contexts as global boolean switches:
   if (Context.isPromoted("Debugging Java")) {
        new MessageDialog("Quit Fooling Around!").open();
   } 

6. I suggest a language change: 
       promote a Context        ->
enable a Context 
       demote a Context        ->
disable a Context 
This is more palleable to non-native speakers (like me)

7. The most fundemental gripe:  Command, Context, and Role
should not be defined in org.eclipse.ui, but in org.eclipse.core.
Everything in the platform is driven by what role a user plays.
Based on their role, certain plugins are loaded and shown.
Heck, the entire loading mechanism may be different. Based
on what context is enabled, help is affected (certain help
categories shown, other hidden). Nothing you don't need for
your Role is loaded at all. Has to be in core for this reason.
Many technologies have the notion of Command. Should
therefore be in a generally available place (also for 
headless Eclipse incarnations).
Action is something that belongs in org.eclipse.ui.
Command is something that belongs in org.eclipse.core.actions

Chris Laffra