Home » Eclipse Projects » Eclipse Platform » Preferred handling of menu item invocation
| Preferred handling of menu item invocation [message #322249] |
Mon, 12 November 2007 09:17  |
 Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
All,
My understanding is that the Eclipse platform supports various ways of
adding items to menus, toolbars etc., and various ways of handling their
invocation:
1. Using extension point org.eclipse.ui.menus declare a menu, associate
a command with it, associate a handler with the command, implement the
handler.
2. Using extension point org.eclipse.ui.actionSets, declare an action,
associate an action delegate with it, implement the action delegate.
3. Programmatically add implementations of IAction to menus, toolbars, etc.
We started off with #3 (we can do this because we're building a
standalone RCP app), but realized after a bit that this isn't very
flexible. So we're now looking into #1 and #2.
Which is preferred, and why? To me, #1 seems more intuitive, and affords
some direct control over the IAction instance; yet I read that #2 is the
"new" (and therefore preferred?) way of doing things. But in method #2,
it seems the app code doesn't hook in at the GUI level at all. How would
I then, for example, notify the user in the case of an execution problem?
Are there yet other methods to consider?
Thank you,
Jasper.
|
|
|
| Re: Preferred handling of menu item invocation [message #322250 is a reply to message #322249] |
Mon, 12 November 2007 09:34  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Jasper schrieb:
> All,
>
> My understanding is that the Eclipse platform supports various ways of
> adding items to menus, toolbars etc., and various ways of handling their
> invocation:
>
> 1. Using extension point org.eclipse.ui.menus declare a menu, associate
> a command with it, associate a handler with the command, implement the
> handler.
>
> 2. Using extension point org.eclipse.ui.actionSets, declare an action,
> associate an action delegate with it, implement the action delegate.
>
> 3. Programmatically add implementations of IAction to menus, toolbars, etc.
>
> We started off with #3 (we can do this because we're building a
> standalone RCP app), but realized after a bit that this isn't very
> flexible. So we're now looking into #1 and #2.
>
> Which is preferred, and why? To me, #1 seems more intuitive, and affords
> some direct control over the IAction instance; yet I read that #2 is the
> "new" (and therefore preferred?) way of doing things. But in method #2,
It's the other way round :-) Go with menus-Extension-Point! Currently
the whole eclipse core platform is migrated to commands.
Using commands all over ensures:
- that you can Unit-Test your actions
- get informed about execution, ... .
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: Preferred handling of menu item invocation [message #322282 is a reply to message #322250] |
Tue, 13 November 2007 05:34 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
Thanks.. but with the command handlers I find that even basic things are
cumbersome. For example, a pretty simple operation is to open up a
wizard. With actions, the constructor gets passed a reference to
IWorkBenchWindow, so it's easy. However, with a command handler, the
only way I have found to do this is:
IWorkbenchWindow window = null;
Object appContextObj = event.getApplicationContext();
if (appContextObj instanceof IEvaluationContext) {
IEvaluationContext appContext = (IEvaluationContext)appContextObj;
window = (IWorkbenchWindow)appContext.getVariable(
ISources.ACTIVE_WORKBENCH_WINDOW_NAME);
}
WizardDialog dialog = new WizardDialog(
window.getShell(), new MyWizard());
dialog.open();
That's a lot of code for something that used to take only 1 or 2 lines.
Is there a better way?
Thanks
Jasper.
Tom Schindl wrote:
> Jasper schrieb:
>> All,
>>
>> My understanding is that the Eclipse platform supports various ways of
>> adding items to menus, toolbars etc., and various ways of handling
>> their invocation:
>>
>> 1. Using extension point org.eclipse.ui.menus declare a menu,
>> associate a command with it, associate a handler with the command,
>> implement the handler.
>>
>> 2. Using extension point org.eclipse.ui.actionSets, declare an action,
>> associate an action delegate with it, implement the action delegate.
>>
>> 3. Programmatically add implementations of IAction to menus, toolbars,
>> etc.
>>
>> We started off with #3 (we can do this because we're building a
>> standalone RCP app), but realized after a bit that this isn't very
>> flexible. So we're now looking into #1 and #2.
>>
>> Which is preferred, and why? To me, #1 seems more intuitive, and
>> affords some direct control over the IAction instance; yet I read that
>> #2 is the "new" (and therefore preferred?) way of doing things. But in
>> method #2,
>
> It's the other way round :-) Go with menus-Extension-Point! Currently
> the whole eclipse core platform is migrated to commands.
>
> Using commands all over ensures:
> - that you can Unit-Test your actions
> - get informed about execution, ... .
>
> Tom
>
|
|
|
| Re: Preferred handling of menu item invocation [message #322284 is a reply to message #322282] |
Tue, 13 November 2007 06:33 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
OK, I found HandlerUtil.getActiveWorkbenchWindowChecked(event)....
:-)
Jasper wrote:
> Thanks.. but with the command handlers I find that even basic things are
> cumbersome. For example, a pretty simple operation is to open up a
> wizard. With actions, the constructor gets passed a reference to
> IWorkBenchWindow, so it's easy. However, with a command handler, the
> only way I have found to do this is:
>
> IWorkbenchWindow window = null;
> Object appContextObj = event.getApplicationContext();
> if (appContextObj instanceof IEvaluationContext) {
> IEvaluationContext appContext = (IEvaluationContext)appContextObj;
> window = (IWorkbenchWindow)appContext.getVariable(
> ISources.ACTIVE_WORKBENCH_WINDOW_NAME);
> }
> WizardDialog dialog = new WizardDialog(
> window.getShell(), new MyWizard());
> dialog.open();
>
> That's a lot of code for something that used to take only 1 or 2 lines.
>
> Is there a better way?
>
> Thanks
> Jasper.
>
>
>
> Tom Schindl wrote:
>> Jasper schrieb:
>>> All,
>>>
>>> My understanding is that the Eclipse platform supports various ways
>>> of adding items to menus, toolbars etc., and various ways of handling
>>> their invocation:
>>>
>>> 1. Using extension point org.eclipse.ui.menus declare a menu,
>>> associate a command with it, associate a handler with the command,
>>> implement the handler.
>>>
>>> 2. Using extension point org.eclipse.ui.actionSets, declare an
>>> action, associate an action delegate with it, implement the action
>>> delegate.
>>>
>>> 3. Programmatically add implementations of IAction to menus,
>>> toolbars, etc.
>>>
>>> We started off with #3 (we can do this because we're building a
>>> standalone RCP app), but realized after a bit that this isn't very
>>> flexible. So we're now looking into #1 and #2.
>>>
>>> Which is preferred, and why? To me, #1 seems more intuitive, and
>>> affords some direct control over the IAction instance; yet I read
>>> that #2 is the "new" (and therefore preferred?) way of doing things.
>>> But in method #2,
>>
>> It's the other way round :-) Go with menus-Extension-Point! Currently
>> the whole eclipse core platform is migrated to commands.
>>
>> Using commands all over ensures:
>> - that you can Unit-Test your actions
>> - get informed about execution, ... .
>>
>> Tom
>>
|
|
|
| Re: Preferred handling of menu item invocation [message #322305 is a reply to message #322282] |
Tue, 13 November 2007 14:29 |
|
Jasper wrote:
>
> IWorkbenchWindow window = null;
> Object appContextObj = event.getApplicationContext();
> if (appContextObj instanceof IEvaluationContext) {
> IEvaluationContext appContext = (IEvaluationContext)appContextObj;
> window = (IWorkbenchWindow)appContext.getVariable(
> ISources.ACTIVE_WORKBENCH_WINDOW_NAME);
> }
> WizardDialog dialog = new WizardDialog(
> window.getShell(), new MyWizard());
> dialog.open();
Yes, it's a lot of code ... although I see you found HandlerUtil :-)
The idea with commands/handlers and the IEvaluationContext is to provide
the workbench state that they handler needs in one place. It's close in
3.3, and in 3.4 we hope to never see a: PlatformUI.getWorkbench()...
The action framework (actionSets, editorActions, viewActions,
popupMenus) specifies visibility, rendering, behaviour, and lifecycle
all in one place. If it did exactly what you wanted, that was great,
and if not, there was no flexibility.
Commands, handlers, and menu contributions have a lot more flexibility
on how they are used ... but they have the added complexity. We try and
mitigate it with helpers like HandlerUtil, though.
Later,
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Goto Forum:
Current Time: Thu Jul 04 19:14:07 GMT 2024
Powered by FUDForum. Page generated in 0.03123 seconds |
] 
Search
Help
Register
Login
Home
