[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Canadian Idol - or - follow your role-model: Contexts, Commands, Actions
|
Most important things first:
Considering we don't really have a proposal style - we have a style for
articles, I suppose, but most docs on team pages are "anything-goes" style,
I added a W3C core style - and they are just so darn pretty, don't you
think? Plus they are complete so it is easy to do just logical markup and
add a one line <link/> tag. I suppose I *could* borify it an order of
magnitude for you.. (sigh..)
Now for the roles/contexts stuff:
What a coincidence you brought up roles. We have added support for roles
just this week, in fact, as part of a scalability experiment. And we've
formed one of those 'dynamic teams' to help address these issues. Some
working definitions:
Roles describe what the user is capable of / or responsible for performing.
Contexts describe what the user is currently doing.
I usually express roles in noun form. i.e. "Farmer" is a role and I express
contexts in gerund form i.e. "Farming" is a context.
Clearly there is a relationship between the two, in the simplest case, this
relationship is 1:1. Many to one relationships are also possible: A person
acting in the role of "Java Developer" should be able to get to the point
in the application where he is "Editing Java Source" (context) or
"Debugging Java Software" (context). Add to this other external variables,
such as skill level of user, other workflow events, etc. and more complex
relationships between roles and contexts (and these variables) can be
described.
Consider:
* A user can be acting in one or more roles. We haven't figured out how the
user will change his role or roles yet - possibly on some sort of
uber-welcome page. In any case, users wouldn't change roles very often.
* A role defines a set of "recommended" contexts. For instance, the role
of "Java Developer" would mark the "Developing Software", "Editing Java
Source", and "Working with CVS" contexts, etc. as "recommended"
* Various systems within Eclipse (new project, import, preference pages,
commands, views, editors, perspectives, help) are bound to contexts. The
precise meaning of the association depends on the particular system.
* Contexts maintain two pieces of state: 1. whether or not they are
recommended (this is based on the user's role). 2. whether or not they are
active (what the user is doing at the time). These are mutually exclusive.
It is possible to have a recommended context, but not currently active, and
visa versa. I will retire the terms 'promote and demote' in favor of
'active and inactive'.
If I am in the role of "Business Guy", the UI should attempt to downplay or
otherwise move into the periphery operations that may cause eclipse to
activate contexts not recommended for the user's current role or roles. Say
"Business Guy" goes to the new project wizard. He should probably not see
"New J2EE Project", rather only those projects which he is typically
interested in or qualified to use - like maybe "New Business Model
Project". Of course, there is a way for "Business Guy" to start "New J2EE
Project" - he might be a former software developer - but here the UI has
enough information to warn the user that what he is about to do is outside
his role.
For instance: "Are you sure you want to do this? [yes] [no] [x] don't ask
me again". If the user chooses 'No', the UI kept the user safe from areas
he may quickly get lost in. If the user chooses 'Yes', eclipse allows the
user to continue, which could lead to the case of one or more unrecommended
contexts activating. If the user chooses 'yes, and don't ask me again', the
user has explicitly chosen to expand his role in a custom manner - specific
contexts outside the user's role should now also be considered as
recommended.
Not all systems interpret their association to context in terms of
'recommended/not recommended' like the above example of the 'new project'
wizard. Some systems, like the commands system, would make decisions on
whether or not a context is 'active'. For instance, the "Java Developer"
role may recommend the "Editing Java Source" context, but that doesn't mean
the commands on the Source menu should be visible until that context is
actually active. i.e. the "Java Developer" actually begins editing Java
source, causing the "Editing Java Source" context to become active.
ok. where am i.. I lost myself..
Oh yes, so for hierarchical contexts, I agree this might be a problem.
Maybe they should be flat. Maybe they should go the other way and be more
of a graph. The idea is that if you are "Editing Java Source" (context)
that automatically implies you are "Editing Text" (context) so the idea
here was to ensure that the set of active contexts would always maintain
integrity.
As for moving this stuff out of workbench, I agree. Should it go down to
core? I'm not sure that is necessary. As part of the roles work this week,
the dynamic team (myself, tod creasey, kim horne, and andre weinand) have
been looking at binding roles to entire plugins and other such fun, goofy,
stuff.
Ideally, I'd like new plugins org.eclipse.ui.roles,
org.eclipse.ui.contexts, and org.eclipse.ui.commands. There are currently
jface dependancies (minor) as well as core.registry dependancies
(significant) on these three pieces of work. There are no dependancies on
workbench.
Chris.
|---------+--------------------------------->
| | Chris |
| | Laffra/Ottawa/IBM@IBMC|
| | A |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 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
