[platform-ui-dev] Canadian Idol - or - follow your role-model: Contexts,

[Chris Laffra <Chris_Laffra@xxxxxxxxxx>]

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