Home » Eclipse Projects » Rich Client Platform (RCP) » How to realize perspective-specific dynamic actions
| |
| Re: How to realize perspective-specific dynamic actions [message #453257 is a reply to message #453184] |
Tue, 25 July 2006 06:22   |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Paul Webster wrote:
> Daniel Krügler wrote:
>
>> Hello,
>>
>> I would like to add perspective-specific actions into the
>> main menu - if possible, it should be done declaratively.
>> Actually the proper solution would be the ext. pt.
>> org.eclipse.ui.perspectiveExtensions. But in my use-case
>> this special sequence of actions is determined *once* during
>> run-time (thus the declarative solution is impossible).
>
>
> Do you mean choosing between 2 actionSets, for example, depending on
> some programmatic decision?
>
> You could create the 2 actionSets with visible false, and then use
> IWorkbenchPage#showActionSet(*) to make it appear in the current
> perspective.
Regrettably the use-case is more complicated. Lets assume a
client-server program, where the client RCP gets after login
user-dependent information from a service, which's result determine the
*number* and the concrete *kind* of the actions. It is possible to
*generate* concrete actions from this information at that moment. Note
that this leads to changes in the main menu just after a login change,
so from the users point it remains constant during her login time. Now
we also have the situation, that these actions are only allowed to be
presented in dedicated perspectives. It would be OK, to assign all these
actions to the same action set, I think. So I could solve parts of the
problem by defining this special action set via the ext pt.
org.eclipse.ui.perspectiveExtensions to ensure its restriction to a
statically known set of perspectives. But how can I realize the very
problem that I need to:
- remove all previously assigned actions from this special action set.
- add the newly created (user-dependent) set of actions to this action set.
Both things needs to happen during runtime just after login change.
Side note: In the moment, every login change enforces a restart of the
application, so I would also appreciate any solution, where we have the
simplified situation that this sequence of actions is assigned to an
action set at the earliest possible stage (i.e. workbench advisor
creation time). But the basic problem remains: Both the number and the
concrete appearance (images, etc.) can only be determined at this point
of run-time and not statically/declaratively.
Its tough, isn't it? ;-)
Greetings,
Daniel
|
|
|
| Re: How to realize perspective-specific dynamic actions [message #453270 is a reply to message #453257] |
Tue, 25 July 2006 14:05 |
|
So it really depends on what you mean by *kind* of actions.
If you have a set of 20 actions, and depending on who logs in they will
have access to 1 or more, you can do that by breaking out action sets
and using the login information to showActionSet(*)/hideActionSet(*).
Or the actions can all be in activities, and have the activities enabled
or disabled depending on the login information.
Especially if you can break them up into 3 or 4 groups, check out
eclipse-jaas which can load the appropriate plugins based on the login
authentication and authorization.
If you really have to generate information, you could create plugin jars
on the fly and load them into eclipse. As long as they are
self-contained and clean up after themselves they should load and
unload. Always risky, but doable :-)
You use BundleContext#installBundle(*) to dynamically install the
bundle, and then the actions you defined would show up.
At the end, you can uninstall the bundle, and that would make them
disappear ... but of course, you have to be careful to make your little
plugin dynamically compatible (it needs to clean up every listener,
resource, etc when it's uninstalled/unloaded, or you'll get exceptions).
org.eclipse.ui.tests has a TestInstallUtil class that has an example of
using the BundleContext to load and unload a plugin.
Later,
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: How to realize perspective-specific dynamic actions [message #453273 is a reply to message #453270] |
Tue, 25 July 2006 14:46 |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Paul Webster wrote:
> If you have a set of 20 actions, and depending on who logs in they will
> have access to 1 or more, you can do that by breaking out action sets
> and using the login information to showActionSet(*)/hideActionSet(*).
The situation is that the server already has done the user-filtering, so
the client gets an (possibly empty) array of information from which it
can create IAction items. So its actually simpler than you describe: The
client does not have to care about the enablement of the constructed
actions (they are all enabled for a special perspective), but it does
not know its actual number and nature in advance. This information is
available at the point of login and not earlier. As I said: To simplify
matters: We can assume that this information is available at the point
where the workbench advisor is created, because at least currently a
login change leads to a restart. The most simple solution would be, if
one could assign an action *group* to a declarative action set (which I
can restrict to selected perspectives). But that is not possible, is it?
> Or the actions can all be in activities, and have the activities enabled
> or disabled depending on the login information.
>
> Especially if you can break them up into 3 or 4 groups, check out
> eclipse-jaas which can load the appropriate plugins based on the login
> authentication and authorization.
Regrettably that is not possible, because the client needs the
server-provided information to get both the number and the nature of the
actions. You can think of a service which returns
SomeUniqueIdentifier[]. There exist an unlimited number of possible
SomeUniqueIdentifier's, so the client can't provide statically prepared
actions for every possible one.
> If you really have to generate information, you could create plugin jars
> on the fly and load them into eclipse. As long as they are
> self-contained and clean up after themselves they should load and
> unload. Always risky, but doable :-)
>
> You use BundleContext#installBundle(*) to dynamically install the
> bundle, and then the actions you defined would show up.
>
> At the end, you can uninstall the bundle, and that would make them
> disappear ... but of course, you have to be careful to make your little
> plugin dynamically compatible (it needs to clean up every listener,
> resource, etc when it's uninstalled/unloaded, or you'll get exceptions).
>
> org.eclipse.ui.tests has a TestInstallUtil class that has an example of
> using the BundleContext to load and unload a plugin.
That seems an interesting procedure, although quite advanced.
If you say that I have to uninstall every listener: Do you think that
this is possible, if I use declarative actions inside that created
plug-in? The problem is that I would have to know, where they have been
registered by the platform, AFAIK many parts of the declarative action
registration is done internally, right?
Thank you very much for your thorough information! I hope you don't
think that it I'm unthankful if I say, that I hope that it would be
possible to solve it in a more simple manner (action groups assignable
to action sets?)
Greetings,
Daniel
|
|
| |
Goto Forum:
Current Time: Thu Oct 03 21:10:11 GMT 2024
Powered by FUDForum. Page generated in 0.02965 seconds |
] 
Search
Help
Register
Login
Home
