[
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
|
see my comment to randy, plus check out the archives of this list for a
discussion on action vs. command that took place recently (within the last
month, i think..)
i appreciate that to developers there is this common use of the term in
the "command" pattern, which i reiterate is not a part of eclipse api
right now.
also, action vs. command is confusing. i personally wish command and
action didn't appear together.
"command" and "handler" would be more appropriate, and we could retire the
term action. (and yes, you don't have to tell me of all the implications
of that statement, and how its much too late for that, etc.)
even "action" and "handler" would be a good combo, assuming we use
"action" to mean my use of the term "command" and "handler" to mean part
of the current use of the term "action", if you can follow that statement.
(i'm not sure i can either, and i just wrote it.)
how about we leave "action" to eventually be retired, leave "command" for
a future undo/redo stack, and introduce terms "request" and "handler".
(of course, *now* i think i'm being facetious :)
whatever the terminology needs to be...
one of the goals from the ui team is the decoupling of
menus/toolbars/keybindings/scripting/etc from handlers (or "actions"). the
"command" was injected into the middle of this as the vehicle for this
decoupling. key bindings are already defined in terms of commands which
don't care where the actual handler ("action") or handlers (in the case of
"retargetable actions") are. it was this (possible) one-many relationship
between what we want to put on a menu and toolbar ("command") and its
handlers ("actions") that was the impetus for this change.
part of the confusion surely must be that the work on the plan item isn't
finished yet. the action contribution story is not complete, rather in
transition. there is still duplicity in the api. there are no menus and
toolbars extension point for explicitely defining these items in terms of
commands. menu and toolbar path attributes on action have not yet been
deprecated. it is not yet documented that images can now be bound to
command objects for use on toolbars, etc. we are looking the idea of a
"CommandContributionItem" to (ideally) replace "ActionContributionItem"
for the current MenuManager. a larger step might be to take another look
from scratch at how menus and toolbars should be formed (the
aforementioned not-yet-existent menus and toolbars extension points for
instance..) there are many things to be done (tried? then proposed?) over
the next milestone or two before this complex picture can be made clear.
Chris Laffra/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
09/11/2003 11:22 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc: platform-ui-dev@xxxxxxxxxxx, platform-ui-dev-admin@xxxxxxxxxxx
Subject: 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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
