Home » Eclipse Projects » Eclipse Platform » org.eclipse.ui.menus vs. actionContribution
| org.eclipse.ui.menus vs. actionContribution [message #317497] |
Thu, 05 July 2007 05:33  |
Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
I am about switching my RCP from actionContribution extension points to
the new command based ones.
1. What is the goal of the future development ?
The documentation speeks about a replacement of the old action
contribution ext. points. Will they become deprecated ?
2. If so, there are some dependencies which still must be resolved.
I use an org.eclipse.ui.perspectiveExtension to contribute an ActionSet
wich should only be visible in a special perspective.
How can I achive this behaviour using the command based / ui.menus
extension points ?
I haven't found a mechanism in core.expression for the current perspective.
3. Is there a way to contribute those commands programmaticly ?
In IPerspectiveFactory I can only add an declared ActionSet via IPageLayout.
Thank You
Sebastian
|
|
|
| Re: org.eclipse.ui.menus vs. actionContribution [message #317502 is a reply to message #317497] |
Thu, 05 July 2007 10:00  |
| Eclipse User |
|
|
|
Sebastian Fuchs wrote:
> I am about switching my RCP from actionContribution extension points to
> the new command based ones.
>
> 1. What is the goal of the future development ?
> The documentation speeks about a replacement of the old action
> contribution ext. points. Will they become deprecated ?
That was the hope, although I'm still on the fence. What might happen
is they continue to live in 3.x (3.4, 3.5) but disappear from 4.0. And
the underlying implementation would still change in the 3.x stream.
> 2. If so, there are some dependencies which still must be resolved.
> I use an org.eclipse.ui.perspectiveExtension to contribute an ActionSet
> wich should only be visible in a special perspective.
> How can I achive this behaviour using the command based / ui.menus
> extension points ?
> I haven't found a mechanism in core.expression for the current perspective.
You are correct, in 3.3 there isn't a "currentPerspective" variable.
You can find out by creating a workbench window property tester, but
changing perspectives won't issue an update event (although other things
might). The equivalent idea to actionSets in menu contributions are
contexts. i.e. you would tie your menu contribution visibility to a
context whose parent is org.eclipse.ui.contexts.actionSet (need to check
the code for this).
Then the part that is missing is an easy way to allow the user to
activate/deactivate that context with perspective switching. In 3.3 if
you define an empty actionSet, you can use that ID as a context in your
core expressions. Check out http://wiki.eclipse.org/Menu_Contributions
which has examples that I hope to update shortly and
http://wiki.eclipse.org/Command_Core_Expressions for things you can
currently do with core expressions.
>
> 3. Is there a way to contribute those commands programmaticly ?
> In IPerspectiveFactory I can only add an declared ActionSet via
> IPageLayout.
The commands framework contains 5 main parts:
org.eclipse.ui.commands - there are ways to contribute programmatically,
but this is not usually done. Commands are like "abstract global
retargetable actions". Commands tend to be static, and the handlers
change a lot.
org.eclipse.ui.handlers - handlers can also be activated
programmatically by views, by editors, by actions, etc.
org.eclipse.ui.bindings - key bindings cannot be contributed
programmatically
org.eclipse.ui.menus - you can programmatically contribute the menu
contributions ... but you don't use it the same way you use IActionBars,
that's not what it is for.
org.eclipse.ui.contexts - there was ways to contribute programmatically,
but this is not usually done. You can programmatically activate and
deactivate contexts fairly easily, however.
Later,
PW
|
|
|
| Re: org.eclipse.ui.menus vs. actionContribution [message #317507 is a reply to message #317502] |
Thu, 05 July 2007 10:45 |
| Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
Thank You Paul,
I'll see what 3.4 or 3.5 brings.
Regards
Sebastian
Paul Webster schrieb:
> Sebastian Fuchs wrote:
>> I am about switching my RCP from actionContribution extension points
>> to the new command based ones.
>>
>> 1. What is the goal of the future development ?
>> The documentation speeks about a replacement of the old action
>> contribution ext. points. Will they become deprecated ?
>
> That was the hope, although I'm still on the fence. What might happen
> is they continue to live in 3.x (3.4, 3.5) but disappear from 4.0. And
> the underlying implementation would still change in the 3.x stream.
>
>
>> 2. If so, there are some dependencies which still must be resolved.
>> I use an org.eclipse.ui.perspectiveExtension to contribute an
>> ActionSet wich should only be visible in a special perspective.
>> How can I achive this behaviour using the command based / ui.menus
>> extension points ?
>> I haven't found a mechanism in core.expression for the current
>> perspective.
>
> You are correct, in 3.3 there isn't a "currentPerspective" variable. You
> can find out by creating a workbench window property tester, but
> changing perspectives won't issue an update event (although other things
> might). The equivalent idea to actionSets in menu contributions are
> contexts. i.e. you would tie your menu contribution visibility to a
> context whose parent is org.eclipse.ui.contexts.actionSet (need to check
> the code for this).
>
> Then the part that is missing is an easy way to allow the user to
> activate/deactivate that context with perspective switching. In 3.3 if
> you define an empty actionSet, you can use that ID as a context in your
> core expressions. Check out http://wiki.eclipse.org/Menu_Contributions
> which has examples that I hope to update shortly and
> http://wiki.eclipse.org/Command_Core_Expressions for things you can
> currently do with core expressions.
>
>>
>> 3. Is there a way to contribute those commands programmaticly ?
>> In IPerspectiveFactory I can only add an declared ActionSet via
>> IPageLayout.
>
> The commands framework contains 5 main parts:
>
> org.eclipse.ui.commands - there are ways to contribute programmatically,
> but this is not usually done. Commands are like "abstract global
> retargetable actions". Commands tend to be static, and the handlers
> change a lot.
>
> org.eclipse.ui.handlers - handlers can also be activated
> programmatically by views, by editors, by actions, etc.
>
> org.eclipse.ui.bindings - key bindings cannot be contributed
> programmatically
>
> org.eclipse.ui.menus - you can programmatically contribute the menu
> contributions ... but you don't use it the same way you use IActionBars,
> that's not what it is for.
>
> org.eclipse.ui.contexts - there was ways to contribute programmatically,
> but this is not usually done. You can programmatically activate and
> deactivate contexts fairly easily, however.
>
>
> Later,
> PW
|
|
|
| Re: org.eclipse.ui.menus vs. actionContribution [message #317522 is a reply to message #317507] |
Thu, 05 July 2007 19:16 |
| Eclipse User |
|
|
|
Sebastian Fuchs wrote:
> Thank You Paul,
>
> I'll see what 3.4 or 3.5 brings.
If it doesn't provide new capabilities that you need it's not necessary
to switch to commands in 3.3. However, when writing new code I would
use commands first and then actions only if I had to.
Just some random information: The action extensions, like actionSets,
bind you to a location, a lifecycle, and a visibility. Commands are a
slight reorginization of that that provides much more flexibility.
Commands are just an abstract representation of a behaviour ... like
COPY, PASTE, SHOW VIEW, etc. Depending on the global application
context, different handlers are active and the handler is what gives the
commands their behaviour.
Commands also fire pre and post events on execution.
Menu contributions use the commands pattern (like core expression for
visibility) and have more flexibility than any of the action extension
points.
PW
|
|
|
| Re: org.eclipse.ui.menus vs. actionContribution [message #317528 is a reply to message #317522] |
Fri, 06 July 2007 03:41 |
| Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
As I have seen in the documentation and the wiki pages, commands are
really the more flexible way. I follow your advice and will prefere
commands.
In past I already encountered some design problems, when having to
trigger the same logic (actually the same action from the user's point
of view) once by a declarative action and programmaticly. That required
to have either two Action classes or to have one Action class
implementing IWorkbenchWindowActionDelegate - which results in having 2
entry points - the constructor and #init().
Genrally, what is the prefered way to add logic - programmatic or
declarativ ?
I use to code as much as possible and only declare when I don't have
access to the code (foreign plugin). This way I get the most out of
compiler time error checking.
On the other hand I can imagine that declaring logic prevents from
unnescessary plugin-loading.
Regards
Sebastian
Paul Webster schrieb:
> Sebastian Fuchs wrote:
>> Thank You Paul,
>>
>> I'll see what 3.4 or 3.5 brings.
>
> If it doesn't provide new capabilities that you need it's not necessary
> to switch to commands in 3.3. However, when writing new code I would
> use commands first and then actions only if I had to.
>
> Just some random information: The action extensions, like actionSets,
> bind you to a location, a lifecycle, and a visibility. Commands are a
> slight reorginization of that that provides much more flexibility.
> Commands are just an abstract representation of a behaviour ... like
> COPY, PASTE, SHOW VIEW, etc. Depending on the global application
> context, different handlers are active and the handler is what gives the
> commands their behaviour.
>
> Commands also fire pre and post events on execution.
>
> Menu contributions use the commands pattern (like core expression for
> visibility) and have more flexibility than any of the action extension
> points.
>
> PW
|
|
|
| Re: org.eclipse.ui.menus vs. actionContribution [message #317620 is a reply to message #317528] |
Tue, 10 July 2007 10:00 |
| Eclipse User |
|
|
|
Sebastian Fuchs wrote:
> Genrally, what is the prefered way to add logic - programmatic or
> declarativ ?
The more you can add declaratively, the better off you are. Most
eclipse platform extensions are designed declaratively first (i.e. the
extension point), and then the minimal programmatic API is exposed later.
> I use to code as much as possible and only declare when I don't have
> access to the code (foreign plugin). This way I get the most out of
> compiler time error checking.
> On the other hand I can imagine that declaring logic prevents from
> unnescessary plugin-loading.
That is one of the main goals of the extension registry (although not
the only one). It is also often important because of the OSGi framework
handling of classpaths.
Later,
PW
|
|
|
Goto Forum:
Current Time: Tue Jul 15 14:53:27 EDT 2025
Powered by FUDForum. Page generated in 0.08596 seconds |
Home