Preferences - Properties in non UI plugin and UI plugin [message #1746276] |
Wed, 26 October 2016 11:22 |
Djak Mising name Messages: 16 Registered: November 2010 |
Junior Member |
|
|
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 11:26] Report message to a moderator
|
|
|
Re: Preferences - Properties in non UI plugin and UI plugin [message #1746428 is a reply to message #1746276] |
Fri, 28 October 2016 14: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 #1746655 is a reply to message #1746627] |
Wed, 02 November 2016 14:01 |
Eclipse User |
|
|
|
The class org.eclipse.core.runtime.Preferences is deprecated. The extension point org.eclipse.core.runtime.preferences is not.
One thing I forgot to mention, that you discovered, is that ScopedPreferenceStore implicitly consults the DefaultScope by default.
And one thing to be careful: Platform.getProduct() is your active product. You can have several products in one installation, and one is set as the default. Your use of 'Platform.getProduct().getId()' could bite you if you ever ship multiple products. For example, many of the Eclipse Packages include multiple products, such as the Eclipse IDE for RCP Developers which includes org.eclipse.platform.ide, org.eclipse.sdk.ide, and an org.eclipse.epp.package.rcp.product.
Brian.
Brian.
|
|
|
|
|
|
Re: Preferences - Properties in non UI plugin and UI plugin [message #1752501 is a reply to message #1752201] |
Tue, 24 January 2017 14:28 |
Djak Mising name Messages: 16 Registered: November 2010 |
Junior Member |
|
|
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 14:32] Report message to a moderator
|
|
|
Re: Preferences - Properties in non UI plugin and UI plugin [message #1752615 is a reply to message #1752501] |
Wed, 25 January 2017 15:33 |
Eclipse User |
|
|
|
The default initializers only work for preference nodes ids that match the bundle symbolic name. There's no other way for the workbench to know which initializers to call.
An alternative to using the default preference initializers is to use a bundle activator to configure the different DefaultScopes. But you must ensure you somehow trigger that bundle. Or perhaps re-implement something similar to how the default preference initializers are triggered (I don't recall the mechanism off-hand). Or you could use the org.eclipse.ui.startup extension point to provide org.eclipse.ui.IStartup listener to load them on workbench startup, and you could use an IWorkbenchListener to write out the preference values to a single value on exit.
Brian.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02220 seconds