|
| Re: Using Preferences in RAP [message #1103065 is a reply to message #1102245] |
Fri, 06 September 2013 10:46   |
 Ivan Furnadjiev
Messages: 2426
Registered: July 2009
Location: Sofia, Bulgaria |
Senior Member |
|
|
Hi Mark,
the PreferenceStore ( WorkbenchPlugin.getDefault().getPreferenceStore()
) has a session scope. Does it serve your needs? See also:
AbstractUIPlugin#getPreferenceStore() and
org.eclipse.rap.ui.internal.preferences.SessionScope.
Best,
Ivan
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.
--
Ivan Furnadjiev
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: Using Preferences in RAP [message #1103308 is a reply to message #1103065] |
Fri, 06 September 2013 15:52 |
Mark Leone
Messages: 69
Registered: April 2012 |
Member |
|
|
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.01516 seconds
] 
Search
Help
Register
Login
Home
