Eclipse Community Forums: Rich Client Platform (RCP)

Help

Home

Home » Eclipse Projects » Rich Client Platform (RCP) » Update problems

Show: Today's Messages :: Show Polls :: Message Navigator

Update problems [message #452651]

Tue, 11 July 2006 15:26

Alex

Messages: 65
Registered: July 2009

Member

Hi everyone,

we're currently working on a RCP application which is to be used by
different sale departments.

The first release of the application will be the same for all different
departments. However, we plan that some futurous releases shall just
be used by a subset of departments (e.g. a new feature shall just be added
by department A, not by department B).

Our first idea was to add the names of all departments which are allowed
to use a certain feature to its description. Later on we could
filter all of the features that match with the name of the department the
application is currently running. However, each department shall
not know which other departments are working with the same feature(s). For
this reason, the 'department string' must not be visible
within any of the application's wizards or masks.

The second approach was to put one configuration file for each department
on our webserver (where the update site of the application will also be
hosted).
The file contained the names of all features which the corresponding
department may actually use. This file is parsed by our own custom
UpdateAction and by using a filter we assure that the department cannot
install or update any features it is not allowed to.
The problem of this approach: if we add the functionality of automatic
update scheduling then not our custom UpdateAction is being called.
We face the same problem if the we add the ProductConfiguration mask to
our application (where one can also execute the search for new updates)

An idea that should actually work was one directory on the update site for
each department.

I have the following questions:

- is it possible to assign department names to a feature in a way that
they can be read by our update filter but without being displayed
anywhere in our application?
- is it possible to use the update scheduler with a custom UpdateAction??
- is there some smarter way to achieve our task (apart from one directory
on the update site for each department) offered by the RCP API??

Thanks, Alex

Report message to a moderator

Re: Update problems [message #452655 is a reply to message #452651]

Tue, 11 July 2006 17:21

Mike Evans

Messages: 237
Registered: July 2009

Senior Member

On Tue, 11 Jul 2006 15:26:07 +0000 (UTC), Alex wrote:

> Hi everyone,
>
> we're currently working on a RCP application which is to be used by
> different sale departments.
>
> The first release of the application will be the same for all different
> departments. However, we plan that some futurous releases shall just
> be used by a subset of departments (e.g. a new feature shall just be added
> by department A, not by department B).
>
> Our first idea was to add the names of all departments which are allowed
> to use a certain feature to its description. Later on we could
> filter all of the features that match with the name of the department the
> application is currently running. However, each department shall
> not know which other departments are working with the same feature(s). For
> this reason, the 'department string' must not be visible
> within any of the application's wizards or masks.
>
> The second approach was to put one configuration file for each department
> on our webserver (where the update site of the application will also be
> hosted).
> The file contained the names of all features which the corresponding
> department may actually use. This file is parsed by our own custom
> UpdateAction and by using a filter we assure that the department cannot
> install or update any features it is not allowed to.
> The problem of this approach: if we add the functionality of automatic
> update scheduling then not our custom UpdateAction is being called.
> We face the same problem if the we add the ProductConfiguration mask to
> our application (where one can also execute the search for new updates)
>
> An idea that should actually work was one directory on the update site for
> each department.
>
> I have the following questions:
>
> - is it possible to assign department names to a feature in a way that
> they can be read by our update filter but without being displayed
> anywhere in our application?
> - is it possible to use the update scheduler with a custom UpdateAction??
> - is there some smarter way to achieve our task (apart from one directory
> on the update site for each department) offered by the RCP API??
>
> Thanks, Alex

Could you allow the update to download everything then apply security at
runtime via Activity Patterns?

--
Mike E.

Report message to a moderator

Re: Update problems [message #452661 is a reply to message #452655]

Tue, 11 July 2006 20:09

Alex

Messages: 65
Registered: July 2009

Member

Can you tell me more about Activity Patterns?

Thanks Alex

Report message to a moderator

Re: Update problems [message #452687 is a reply to message #452661]

Wed, 12 July 2006 17:44

Mike Evans

Messages: 237
Registered: July 2009

Senior Member

On Tue, 11 Jul 2006 20:09:15 +0000 (UTC), Alex wrote:

> Can you tell me more about Activity Patterns?
>
> Thanks Alex

Lookup Advanced workbench concepts / Filtering large user interfaces /
Activities in th4e Help file.
I use these at start-up to filter out UI stuff a a particular user should
not use (via IWorkbenchActivitySupport.setEnabledActivites() );

--
Mike E.

Report message to a moderator

Re: Update problems [message #452706 is a reply to message #452687]

Thu, 13 July 2006 08:12

Daniel KrÃ¼gler

Messages: 853
Registered: July 2009

Senior Member

Mike Evans wrote:
> On Tue, 11 Jul 2006 20:09:15 +0000 (UTC), Alex wrote:
> Lookup Advanced workbench concepts / Filtering large user interfaces /
> Activities in th4e Help file.
> I use these at start-up to filter out UI stuff a a particular user should
> not use (via IWorkbenchActivitySupport.setEnabledActivites() );

I experienced with activities a while ago and was impressed by their
"capabilities" (pun intended..). We stopped integrating them into our
application, when we found out, that it is possible for the *user* to
bypass them. One example: We would like to reflect user roles onto
visible perspectives and views. That can actually easily solved by
activities, but if you use the predefined perspective bar of Eclipse,
and the user opens the perspective selection view under restricted
conditions there exists a checkbox, which allows him/her to enable even
currently diabled activities....

When I asked how to configure this perspective bar programmatically
*not* to show this checkbox I was told, that actually activities are not
intended to be used for such tasks. Eclipse-Jaas might solve some of
your problems, but it seems too coarse-grained for me to do that,
because it rules complete plugin (de)activations. I would strongly
prefer extension-point-selective (de)activations (which are possible
with activities). Is anyone aware of intends to provide such a framework
for RCP applications?

Greetings from Bremen,

Daniel Krügler

Report message to a moderator

Previous Topic:	activity pattern binding
Next Topic:	Refreshing Tree Viewer

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Dec 30 16:31:57 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter