Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » [commands] Counterpart of activateHandler for dynamic menus?
[commands] Counterpart of activateHandler for dynamic menus? [message #655724] Tue, 22 February 2011 13:14 Go to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
The IHandlerService allows for programmatic creation and activation
of command handlers which is a Good Thing(TM) in some scenarios.

Similarly, sometimes one needs programmatically created menus,
especially if these are dynamic ones. The idiomatic way to realize this
is to create an AbstractContributionFactory instance and use the
IMenuService for the provision of this "service". But there is one
disadvantage of the latter approach: I'm required to provide the
location URI via program code as well. This is very unfortunate, because
this does not allow for a proper separation of the "spacial" declaration
of functionality (usually done via the extension point
org.eclipse.ui.menus where the placement of the contribution is
configured) and the provision of the functionality, i.e. the actual
dynamic creation of the contribution items, which typically needs the
programmatically provided context data.

Does there already exist some support for declarative menu declarations
that are fed by programmatically created contribution items? Note that
in my use-case it would *not* be sufficient to provide the context data
via plugin declaration: This needs to be done within an internal part
within my view (actually at the same point where I would use the
IHandlerService to activate programmatic handlers).

I'm aware that I could define my own osgi or Eclipse UI service to
communicate between the menu creation and the view state, but I would
prefer to use existing architecture, if possible (I consider
SourceProviders as equivalent to UI services in this context).

Thanks & Greetings from Bremen

Daniel Krügler
Re: [commands] Counterpart of activateHandler for dynamic menus? [message #655753 is a reply to message #655724] Tue, 22 February 2011 14:44 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Wouldn't you just use a <dynamic.../> entry and subclass
CompoundContributionItem ? That's the most common way to generate a
part of a menu, or a dynamic submenu.

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Platform_Expression_Framework
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm


Re: [commands] Counterpart of activateHandler for dynamic menus? [message #655787 is a reply to message #655753] Tue, 22 February 2011 15:52 Go to previous messageGo to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
On 2011-02-22 15:44, Paul Webster wrote:
> Wouldn't you just use a <dynamic.../> entry and subclass
> CompoundContributionItem ? That's the most common way to generate a part
> of a menu, or a dynamic submenu.

The problem with this approach is, that the CompoundContributionItem
derivative will be constructed by the extension point registry and thus
it is impossible to inject the state from the local context where this
would be necessary. Compare it with the CollapseAllHandler: We need
to call IHandlerService.activateHandler at the local context where we
know about the Viewer, therefore we can invoke this functiona
programmatically within our hook-contextmenu function of a view-part. I
need exactly the same thing for menus, but see no way for this unless I
provide my own service-oriented machinery.

Or am I just missing a way how an CompoundContributionItem can be
created in a local context but will be used by the <dynamic.../> entry??

Thanks,

- Daniel
Re: [commands] Counterpart of activateHandler for dynamic menus? [message #655806 is a reply to message #655787] Tue, 22 February 2011 16:35 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

On 02/22/2011 10:52 AM, Daniel Krügler wrote:
> The problem with this approach is, that the CompoundContributionItem
> derivative will be constructed by the extension point registry and thus
> it is impossible to inject the state from the local context where this
> would be necessary. Compare it with the CollapseAllHandler: We need
> to call IHandlerService.activateHandler at the local context where we
> know about the Viewer, therefore we can invoke this functiona
> programmatically within our hook-contextmenu function of a view-part. I
> need exactly the same thing for menus, but see no way for this unless I
> provide my own service-oriented machinery.

Bridging local context to menus is not an easy thing.

But the mechanism I've seen used is:

class MyDynamicContribution extends CompoundContributionItem implements
IWorkbenchContribution {


public void initialize(IServiceLocator serviceLocator) {
locator = serviceLocator;
}

}

Then in getContributionItems() you can use the locator to get standard
services, like the IPageService or the IEvaluationService (which gives
you access to the system state, including your view as the active part).

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Platform_Expression_Framework
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm


Re: [commands] Counterpart of activateHandler for dynamic menus? [message #655807 is a reply to message #655806] Tue, 22 February 2011 16:47 Go to previous message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
On 2011-02-22 17:35, Paul Webster wrote:
> On 02/22/2011 10:52 AM, Daniel Krügler wrote:
>> The problem with this approach is, that the CompoundContributionItem
>> derivative will be constructed by the extension point registry and thus
>> it is impossible to inject the state from the local context where this
>> would be necessary. Compare it with the CollapseAllHandler: We need
>> to call IHandlerService.activateHandler at the local context where we
>> know about the Viewer, therefore we can invoke this functiona
>> programmatically within our hook-contextmenu function of a view-part. I
>> need exactly the same thing for menus, but see no way for this unless I
>> provide my own service-oriented machinery.
>
> Bridging local context to menus is not an easy thing.
>
> But the mechanism I've seen used is:
>
> class MyDynamicContribution extends CompoundContributionItem implements
> IWorkbenchContribution {
>
>
> public void initialize(IServiceLocator serviceLocator) {
> locator = serviceLocator;
> }
>
> }
>
> Then in getContributionItems() you can use the locator to get standard
> services, like the IPageService or the IEvaluationService (which gives
> you access to the system state, including your view as the active part).

Thanks for your - as usual - excellent suggestions. I agree that I could
follow this approach, but I would prefer not to :-) Let me explain why:
Only the view internals know about the details of constructing the
contribution items, and I would prefer not to give public access to it.
I think now that I will provide my own service, let's name it
IContributionFactory, which allows me to register a contribution item
factory by ID. In the view part, I will use this service and will
register a local implementation via some unique id (similar to
IHandlerService.activateHandler) and will unregister this in the dispose
function (were I will invoke my IHandlerService.deactivateHandler
functions as well). I will use a reusable CompoundContributionItem
similar to as you suggest which will also implement
IExecutableExtension. This allow me to use the <dynamic>
element via the : notation to define the org.eclipse.ui.menus in the
plugin.xml referring to this reusable CompoundContributionItem. The
implementation of this will also implement IWorkbenchContribution (as
you suggested) to have a service locator handy. By reading the
associated ID from IExecutableExtension it will use the service locator
to get my IContributionFactory service where I have a function that
takes the ID and which returns me the contribution items, voilà!

Thanks again,

- Daniel
Previous Topic:IntroPart behind a proxy
Next Topic:relative placing of views of different plugins
Goto Forum:
  


Current Time: Thu Mar 28 20:49:51 GMT 2024

Powered by FUDForum. Page generated in 0.01493 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top