|Re: Using Preferences in RAP [message #1103065 is a reply to message #1102245]
||Fri, 06 September 2013 10:46
| Ivan Furnadjiev
Registered: July 2009
Location: Sofia, Bulgaria
the PreferenceStore ( WorkbenchPlugin.getDefault().getPreferenceStore()
) has a session scope. Does it serve your needs? See also:
On 9/5/2013 6:04 PM, Mark Leone wrote:
> I need to implement user-specific preferences in my RAP app. I
> understand how to use the SettingStore to store and retrieve user
> preferences based either on a session cookie or a custom
> implementation associating specific IDs to specific data stores.
> My question concerns how to integrate this in a single-sourced app
> that also runs as an RCP app. I don't think there is anything already
> provided that wraps the SettingStore in a Preferences node, so I'm
> intending to implement something like that. We have an
> IPreferenceAccessor that handles retrieving and setting preferences
> based on IScopeContext instances (store, default and search contexts)
> provided in the constructor. My intention is to write an IScopeContext
> instance that wraps a custom implementation of SettingStore, and then
> create an IPreferenceAccessor instance with one or more instances of
> this IScopeContext implementation. This way, the app can use the
> Preferences API as if were an RCP app, and the RAP implementation will
> provide user-specific preferences.
> Does this approach make sense? It's not too much work, but I want to
> make sure I'm not missing something already provided that does all or
> part of what I'm developing.
Professional services for RAP and RCP?
|Re: Using Preferences in RAP [message #1103308 is a reply to message #1103065]
||Fri, 06 September 2013 15:52
| Mark Leone
Registered: April 2012
Thanks for your response, Ivan. I think the PreferenceStore class may suit my needs, but I'd like to explain more clearly my needs and confirm what is the best implementation.|
The RCP app persists user preferences between successive application launches. It stores the preference values in a singleton instance of InstanceScope (InstanceScope.INSTANCE). This works in RAP as well, except of course all users share a single preference scope, which we don't want. So I'm looking for a way to store each user's preferences in a separate scope, and then retrieve the proper preference scope for the authenticated user. Users will authenticate with a cert, and I plan to use the hash of the DN as the ID to associate each user with the proper preference scope. Three approaches come to mind, assuming I understand the APIs correctly.
1. Currently we invoke getNode(qualifer) on the InstanceScope singleton, with qualifier specified as the plugin ID of the plugin that manages the preferences. Could I use for the qualifier, thus storing each user's preference values in a unique location?
If the qualifier does not work as I assume in 1) above, then I could create my own instance of IScopeContext, and have it backed either by the PreferenceStore or the SettingStore, as follows:
2. PreferenceStore: I assume that using WorkbenchPlugin.getDefault().getPreferenceStore() as you suggested would provide preferences scoped for the current session. It's not clear to me if/how that instance would persist preference values between sessions and associate different scopes with each user. But I could instantiate a PreferenceStore object and pass a URI as a string value in the constructor, which specifies the file to which the preference values will be persisted. The URI string would be an absolute path to a file in a user-specific directory inside the state area of the plugin.
3. SettingStore: I could use SettingStore#loadById(String id) to persist data separately for each user, with the id being the hash of the user's DN. As I understand it, the framework will handle the details of associating the respective data stores to the appropriate user. Will the stored .property files be in a known location, so an admin can delete defunct preferences for users who don't log in after a certain amount of time?
Other than option 3 requiring RAP 2.x, is there a particular advantage of 2 or 3 over the other? If option 1 would work, that seems to be the easiest approach.
Powered by FUDForum
. Page generated in 0.01469 seconds