| Preferences - Properties in non UI plugin and UI plugin [message #1746276] |
Wed, 26 October 2016 07:22  |
Eclipse User |
|
|
|
Hi,
in an E3 RCP Application I need to store and retrieve properties from a file. We have a core standalone plugin and an RCP UI plugin. I'm looking for the best way to manage the properties in these two plugins.
At this moment we use java.utils.Properties in the non UI plugin and fill them from a file (eg.: "data.prefs"). The plugin have only read access on the properties.
In the RCP UI plugin we load the file "data.prefs" and fill the Preference service from it, eg. :
IPreferencesService service = Platform.getPreferencesService();
service.getRootNode().node(SCOPE).node(Application.PLUGIN_ID).put(key, value)
then use the service in some JFace preference pages.
(Sorry it's not my own code and I'm trying to explain what I understand about the existent code but it's approximately the scenario)
I'm looking for help to manage all these properties in a better way, using AbstractPreferenceInitializer, etc.
For example, I thought to use IPreferenceStore in the non UI plugin but it's in the jface bundle so it may be non sense to use it in a non UI plugin?
Do you have any advice about managing this? Which bundles/extensions would be the best to use in this case?
Later, I will also split the entire application into several plugins. Each functionality/command will have a non UI core plugin and an UI RCP plugin. So I'd like to make something clean by storing and initializing all properties of each core plugin in the plugins themselves but using only one preference file for the main Application (Host plugin), what do you think about that, would it be the "right" way to do that and do you have some advices to achieve that?
Thanks in advance for any help!
Sebastian
[Updated on: Wed, 26 October 2016 07:26] by Moderator |
|
|
| Re: Preferences - Properties in non UI plugin and UI plugin [message #1746428 is a reply to message #1746276] |
Fri, 28 October 2016 10:12  |
| Eclipse User |
|
|
|
The preferences story in Eclipse is a complicated one. There are 5 preferences stories available to Eclipse plugins.
org.eclipse.core.runtime.Preferences is deprecated and should not be used.
JFace's org.eclipse.jface.preferences.IPreferenceStore/IPersistentPreferenceStore, and its many implementers, presents a flat key-value typed store. It is supported by many JFace and workbench components.
The JRE's java.util.prefs.Preferences presents a tree-based preference store. In fact, 2 tree-based stores: one is for user preferences, the other for system preferences. This model provides a tree-based store. Typically applications use their fully-qualified class names as key prefixes to avoid conflicts.
OSGi extends the JRE model with org.osgi.service.prefs.Preferences/PreferencesService where each preferences service maintains independent per-bundle user and system preference trees. So two bundles can store independent values for a key "com.example.Foo.bar". Which I certainly find a bit confusing.
org.eclipse.core.runtime.preferences.IEclipsePreferences is somewhat based on OSGi's, but instead maintains a set of independently scoped trees (represented by org.eclipse.core.runtime.preferences.IScopeContext). These scopes include:
- per-project: represented by the ProjectScope class
- per-workspace: represented by the InstanceScope class
- per-installation: represented by the ConfigurationScope
- defaults: a non-persisted scope intended to hold onto default values, represented by the DefaultScope
Eclipse provides a org.eclipse.core.runtime.preferences.IPreferencesService to look up preferences that attempts to resolve a key across different scopes (e.g., project, then instance, then configuration, finally the default scope, and if not found then returns the default-default value).
There is support for populating the DefaultScope when a bundle is started using the org.eclipse.equinox.preferences.preferences / org.eclipse.core.runtime.preferences extension point to point to an initializer class. This class will be called into on bundle load. You can actually initialize any scope, not just the DefaultScope.
There is a ScopedPreferenceStore in org.eclipse.ui.preferences that maps a scope (IScopeContext) to JFace's IPreferenceStore. This is pretty handy.
New plugins usually use the scopes approach. You could use the preference initializer to pull in from your external properties.
Using your bundle id as a node value is a common pattern, but you're now tying your preferences to your implementation structure. It may be better to use more meaningful names that remain invariant in the face of refactoring.
If you need to interact with other Java components, use the JRE java.util.prefs package.
|
|
|
|
|
|
|
|
| Re: Preferences - Properties in non UI plugin and UI plugin [message #1752501 is a reply to message #1752201] |
Tue, 24 January 2017 09:28 |
| Eclipse User |
|
|
|
Hi,
yes, here is what I'm doing at this moment in a "non UI" core plugin that have ID "org.txm.tbx.partition":
public class PartitionDimensionsPreferences extends AbstractPreferenceInitializer {
public static final String PREFERENCES_NODE = "org.txm.tbx.partition"; //$NON-NLS-1$
public static final String PREFERENCES_PREFIX = "partition_"; //$NON-NLS-1$
public static final String DIMENSIONS_DISPLAY_PARTS_COUNT_IN_TITLE = PREFERENCES_PREFIX + "dimensions_display_parts_count_in_title"; //$NON-NLS-1$
public static final String DIMENSIONS_SORTED_BY_SIZE = PREFERENCES_PREFIX + "dimensions_sort_by_parts_size"; //$NON-NLS-1$
public PartitionDimensionsPreferences() {
// TODO Auto-generated constructor stub
}
@Override
public void initializeDefaultPreferences() {
Preferences defaultPreferences = DefaultScope.INSTANCE.getNode(PREFERENCES_NODE);
defaultPreferences.putBoolean(DIMENSIONS_DISPLAY_PARTS_COUNT_IN_TITLE, true);
defaultPreferences.putBoolean(DIMENSIONS_SORTED_BY_SIZE, false);
}
}
And in another plugin contributing to the UI, for example in the linked preference page I'm creating a ScopedPreferenceStore:
new ScopedPreferenceStore(InstanceScope.INSTANCE, PartitionDimensionsPreferences.PREFERENCES_NODE);
It works very well for all, default preference, instance/file preference but the file used is "org.txm.tbx.partition.prefs" so we will have one separated file for each of our plugins. Actually this is maybe not a real problem but what I'd like to do was to use only one file for all the plugin preferences. However it's finally maybe not much important as I thought since the system of Eclipse permits to export/import all the plugin preferences in one file even if the original preferences are stored in multiple files.
What I wanted to do was to set the same PREFERENCES_NODE qualifier for most each plugin, for example "org.txm.rcpapplication" but since the plugin IDs are not "org.txm.rcpapplication" the initializers of each plugins are never called (not sure if I am very clear  )
[Updated on: Tue, 24 January 2017 09:32] by Moderator |
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.06776 seconds
Home