[
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
|
Does everyone realize what mess we're getting ourselves into?
"Command" is overloaded inside Eclipse. No matter how many
times I read your description, it remains abstract...
So, a "Command" is a class of actions that are all similar, but
it is not the "real" command pattern, used for undo and redo.
Why then call it Command? Why not ActionClass, or ActionSet,
or (- pun intended - ClassAction, with a set of common ClassActions
called a Suite -> ClassActionSuite)?
I guess I can start my next Eclipse book, titled:
Eclipse: Commands, Actions, and Roles
Enough confusion there to fill a whole book <g>
Anyway, lotta confusion here. If we are not careful, the solution
will be hard to understand, it is going to be difficult what's happening
here, and it won't be easy to fix/maintain a broken command structure.
But, of course you all understand my concerns already.
Chris
|---------+--------------------------------->
| | Randy Hudson |
| | <hudsonr@xxxxxxxxxx> |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 09/11/2003 10:56 AM |
| | Please respond to |
| | platform-ui-dev |
| | |
|---------+--------------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-ui-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-ui-dev] Canadian Idol - or - follow your role-model: Contexts, Commands, Actions |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
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@xxxxxx.c To: platform-ui-dev@xxxxxxxxxxx
om> cc:
Sent by: Subject: [platform-ui-dev]
platform-ui-dev-admin@ Canadian Idol - or - follow your role-model:
eclipse.org Contexts, Commands, Actions
09/11/2003 09:37 AM
Please respond to
platform-ui-dev
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
