Home » Eclipse Projects » Eclipse Platform » To use activities or not use activities... that is the question
| To use activities or not use activities... that is the question [message #298953] |
Wed, 08 February 2006 11:36  |
 MartÃn Pérez Mariñán
Messages: 62
Registered: July 2009 |
Member |
|
|
Hi.
I have been successfully testing activities API. It's a great feature and
very useful.
The problem I'm facing is that my application scenario is a bit different
from traditional applications with only one clear defined entry-point.
I have an application in which the users can browse repositories. They can
have several repositories opened at the same time, and they can have
different roles on each repository. For example, an user can be admin on
repository A, and at the same time he can have only read permissions on
repository B.
I must choose now the security approach, and I have two options:
1 - Disable actions, views, etc. by hand.
2 - Use activity API where possible.
As I said, I have been testing option 2, but I face a little problem. I
have chosen to reload activity status when the user selects the
repository. The problem is that when an user selects a repository in which
he is admin, then he can for example open the admin perspective, with
several admin views. If after doing that, the user selects a repository in
which he has only read permissions, he continues to see that perspective
and that views!!!
Well, by usability I would like to maintain that views/perspective on the
screen, but if at least they could be disabled.
I'm beginning to think that my scenario of multiple roles at the same
session is not exactly the best suited for activities API usage.
Any suggestions?
Thanks,
Martin
|
|
| | |
| Re: To use activities or not use activities... that is the question [message #299055 is a reply to message #298964] |
Thu, 09 February 2006 15:14  |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
mpermar wrote:
> Well, knowing when the user change is not a problem for me.
>
> The problem is that if an users is already an admin on a place, in he
> switch to another place, then I will have to programatically close
> "admin perspective" for example. Then, when he selects another tree
> node, he can have again permisions, and then I will have to open again
> the perspective programatically, ....
>
> In summary, too less user-friendly :(
IMHO the key role for support of both role-based behaviour combined with
the corresponding UI persistence is the activation of user-specific
workspace switching. The publicly available API for this exists and you
don't end with the problematic situation that
- User starts as administrator and logouts.
- User re-login as simple user and wonders that she see the previous
admin perspective.
Please note that workspace switching must actually happen **before**
the workbench is created. In our case this is no problem: We have a
log-based start-up. Depending on the accepted user our workspace
switching takes place, then follows the famous call to
PlatformUI.createAndRunWorkbench(). Please inform me, if you are
interested in the details of the workspace switching approach.
Concerning activities: At least in the beginning I thought that the
combination of activities and workspace-switching would provide me with
a lot of Eclipse' built-in behaviour and fulfil our users requests.
At least in the moment I have changed this point of view. The main
problem I see is, that the currently provided entry points of activities
have some hard-coded behaviour which contradicts our whishes. For some
details to this see my contribution "finer-grained control of
activities" from 2nd february this year in the eclipse.platform.rcp
newsgroup. Actually I am somewhat shocked, that no-one has answered to
that thread. In short the problem is the perspective switcher: While
it seems to take activities into account on the first view (as
documented), there exist the programmatically fixed decision that in
case of activities-constrained situations a checkbox occurs, which
effectively allows the user to change to perspectives, for which she has
to "ticket". To my opinion, this behaviour should be modifyable such
that at least programers have control over the visibility of this
checkbox. Paradoxically there exists no such counter part for this in
case of the "Show View" action. So currently we have only the choice
**not** to present the perspective switcher in our RCP app, but we must
program our own switcher. At this point we have to ask ourselves,
which advantages would remain to use the built-in activity support.
The idea is great, but it should be possible to control at least some
parts of the basic Eclipse features which use activities. At least
the mentioned checkbox makes the perspective switcher unusable for our
use cases.
Greetings from Bremen,
Daniel Krügler
|
|
|
Goto Forum:
Current Time: Tue Apr 23 14:48:07 GMT 2024
Powered by FUDForum. Page generated in 0.03142 seconds |
] 
Search
Help
Register
Login
Home
