Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » User preferences implementation(How to implement/extend/utilise user preferences?)
User preferences implementation [message #1226993] Fri, 03 January 2014 08:40 Go to next message
Patrick Mackinlay is currently offline Patrick MackinlayFriend
Messages: 10
Registered: December 2013
Junior Member
I'm interested in understanding the best approach to handle user preferences in my Scout application. So far, I've been able to implement my own IUserPreferencesStorageService backed by a persistence layer on the server, and this is working correctly for Scout's own preferences (e.g. table column layout, etc.).

What I'm now interested in is knowing the best way to utilise this same infrastructure for my own application-specific preferences. In the first instance, I have a simple per-user setting that I'd like persisted between sessions, and it seems to me that the preference mechanism is the right place to put this.

So my questions are:

  1. Am I correct in understanding that IUserPreferencesStorageService (and the ClientUIPreferences class that use it) are fairly tightly coupled, and only intended to handle Scout's own internal preferences requirements?
  2. Given #1, what's the best way to extend the system for my own application's preferences? Should I be tinkering with the Platform.getPreferencesService() service? If so, how do I extend this to handle persistence, and how does it interact with the Scout implementation mentioned earlier?
  3. In simple terms, how do I actually access or interact with user preference values anyway? A quick web search seems to indicate that there are some annotations that are intended to assist with this via dependency injection (see section 2 here). Is this approach suitable for a Scout application?
  4. I've noticed that although my table column layout information is correctly persisted via the preferences mechanism, I'm not seeing the same for the application window size/state, or the position of the splitter bar. Is this normal, or have I overlooked some implementation detail somewhere? I'm using SWT, if it makes any difference.
  5. Not quite on the preferences topic itself, but in my particular case, I want to retrieve a persisted user setting at application start up (after login), and call a service operation using it as a parameter. With respect to the application life cycle, is it "correct" to implement this logic in ClientSession.execLoadSession()?

Thanks in advance for any feedback.
Re: User preferences implementation [message #1234689 is a reply to message #1226993] Wed, 22 January 2014 15:34 Go to previous messageGo to next message
Daniel Branco is currently offline Daniel BrancoFriend
Messages: 14
Registered: January 2014
Junior Member
Hello Patrick,

First of all sorry for not being able to help you, instead I have a question. How did you do to send the preferences to the server?

I was able only to implement the Storage Service and give a name to the prefs file based on the user id.

Practucally this:
return new UserScope().getNode(Activator.PLUGIN_ID + "." + ClientSessionThreadLocal.get().getUserId());

This is enough when working with RAP but SWT keep and load the prefs file locally, so how did you do that?

1. How do you persist thye preferences in server?
2. How do you load the preferences from server?
3. Can you choose wheter you want to persist the preferences in local or in server?

Please refer to this post of mine Preferences and states per User

Thanks in advance and Kind regards.
Re: User preferences implementation [message #1235166 is a reply to message #1226993] Thu, 23 January 2014 17:51 Go to previous messageGo to next message
Claudio Guglielmo is currently offline Claudio GuglielmoFriend
Messages: 153
Registered: March 2010
Senior Member
Hi there

The default FileSystemUserPreferencesStorageService is definitely not useful when using rap. Therefore I opened bug 426493.

In order to store the preferences on the server you could implement lets say ServiceBasedUserPreferences (extends AbstractPreferences) which uses a service to load and store the preferences.

Re: User preferences implementation [message #1236827 is a reply to message #1234689] Tue, 28 January 2014 06:48 Go to previous message
Patrick Mackinlay is currently offline Patrick MackinlayFriend
Messages: 10
Registered: December 2013
Junior Member
Hi Daniel, and sorry for the delay in my response.

Your example code re-uses the standard Eclipse implementation of the Preferences interface (i.e. the UserScope class, etc.), which as you know, is based on text files which must be directly file-accessible to the client. One way of changing this to a mechanism where the preferences data is stored on the server instead (and/or in a database or other persistence mechanism) requires providing your own implementation of the Preferences interface, and returning that to the caller of the loadPreferences() method, rather than the implementation returned by the UserScope().getNode() method.

In my case, I did the following:

  1. Created a new Scout client service which implements the interface.
  2. Created a new inner class within that service which implements the org.osgi.service.prefs.Preferences interface.
  3. Created a new Scout server service which handles the actual persistence (in my case, it reads and writes the user preferences to a Neo4j graph database).

I have probably left out one or two details regarding the configuration steps for the above, but that was where the actual programming was involved. For what it's worth, I'm only targeting SWT, but expect the same approach should work without changes for RAP.

For background, my understanding of how this works is as follows. Firstly, the client application looks for the highest priority implementation of the IUserPreferencesStorageService, and then asks it to return a user preferences object (i.e. something which implements Preferences) by calling its loadPreferences() method. In my case, my Preferences implementation provides a simple wrapper around a local Map<String,Object>, which contains the various user preference key/value pairs. The Map content is retrieved by the server service when the class is instantiated, and stored back to the server when the flush() method is called. In both cases, the server already knows the identity of the user it's interacting with (it's available in the ServerSession), so it can easily retrieve the preference data associated with that calling user.

For what it's worth, my questions about the subject are still open - I don't know how, or if, it's possible to make use of this mechanism for my own application's preferences; right now, it's simply being used to handle Scout's own settings. It also seems to be the case that Scout doesn't use this service a great deal; configuration of "table" views is persisted by this mechanism, but the application window size/position is not, for example.

Finally, it appears that Scout doesn't use any of the parent/child behaviour that the Preferences interface supports, so that makes implementing this a little simpler in the short term.

Previous Topic:working with org.eclipse.scout.rt.ui.rap.workbench
Next Topic:Service reference life cycle
Goto Forum:

Current Time: Tue Mar 28 02:42:19 GMT 2017

Powered by FUDForum. Page generated in 0.02821 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software