ID Options... are not persistet between client sessions

[SSC]

Hello,

we do use the Oxygen 15.1 Auhtor Eclipse plugin.

When the "ID Options..." are modified, those options seem not to be stored.



After adding and closing my Eclipse RCP Client and restarting it, the additional options, which I added, are not available any more.

I guess this is a bug or does it have a reason why those "ID Options..." are not stored?

Best regards,

Simon

[Radu]

Hi Simon,

Basically when our plugin's org.eclipse.core.runtime.Plugin#stop(BundleContext) method gets called our plugin's options are serialized as an XML string which gets saved in the general preferences store org.eclipse.ui.plugin.AbstractUIPlugin.getPreferenceStore() with the key oXygen_Options_Tag.

So if there is a problem with the options persistence, it should affect all options, even checking a certain checkbox in an Oxygen specific preferences page. Can you check this on your side?

I cannot reproduce the problem on my side, I tried on an Eclipse Juno distribution with an installed Oxygen XML Editor 15.1.

What exact version of Eclipse RCP do you have?

Regards,
Radu

[SSC]

Hi Radu,

here is what I have found

What exact version of Eclipse RCP do you have?

We use the 3.6 version of Eclipse.

Basically when our plugin's org.eclipse.core.runtime.Plugin#stop(BundleContext) method gets called

Exactly here lays the problem, because we do store all preferences beforehand in order to persist them on the server-side so that a user can have equal preferences at different locations/maschines or even have different preferences for different purposes.

So you do save your preferences too late for us, because we do attach an IWorkbenchListener and save all preferences, when the IWorkbenchListener#preShutdown method is invoked.

By Default preferences are directly stored, when the user presses the OK Button in the Preferences Dialog.
Under the circumstance that you do not use the PreferenceDialog in that case, we would really appreciate, if you would save your preference directly.
The direct saving of Preferences is also preferable, because listeners for each preference value can be attached, so that the changes can directly be executed. So we would also be able to read your preferences and get to know, when they have changed during a client session.

Would direct saving of your preferences, when they are changed possible for you?

As a workaround until you hopefully implement the "direct saving of preferences", I do like to know, if we are able to store your preferences on our side.

Best regards,

Simon

[Radu]

Hi Simon,

The direct saving of Preferences is also preferable, because listeners for each preference value can be attached, so that the changes can directly be executed. So we would also be able to read your preferences and get to know, when they have changed during a client session.

Because Oxygen is also available as a standalone editor and because we added support to save more complex objects to an XML serialization format our preferences store is not fully synchronized with the Eclipse one. We have our own mechanism of setting options and being notified about them. The notification mechanism is not available in the API.
When the Preferences dialog gets closed or when our plugin gets stopped the Oxygen plugin saves the Oxygen-specific options to an XML String and then sets this XML string in the Eclipse preferences store with the key Author_Options_Tag or oXygen_Options_Tag depending on the plugin type (XML Editor or XML Author).

If I would add some API for you like:

Code: Select all

ro.sync.exml.workspace.api.PluginWorkspace.saveGlobalObjects(String, Object)

which would save to the Eclipse Preferences store all our settings, would that be OK for you? You could call:

Code: Select all

ro.sync.exml.workspace.api.PluginWorkspaceProvider.getPluginWorkspace().saveGlobalOptions()

on your pre-shutdown hook.

Would direct saving of your preferences, when they are changed possible for you?

This would be also an alternative. The specific dialog involved in changing the ID generation options is available as Java source in the Author SDK:

ro.sync.ecss.extensions.commons.id.ECIDElementsCustomizerDialog

and when it closes it calls:

ro.sync.ecss.extensions.commons.id.GenerateIDElementsInfo.saveToOptions(AuthorAccess)

which uses our API:

ro.sync.ecss.extensions.api.OptionsStorage.setOption(String, String)

to save the changes. Maybe our implementation of this OptionsStorage.setOption API could also synchronize with the Eclipse preferences store. I'm reluctant to do this because it might induce some lag, our entire options would need to be saved to XML and this might take a second or so. So adding that extra API for you would be my preferred choice.

As a workaround until you hopefully implement the "direct saving of preferences", I do like to know, if we are able to store your preferences on our side.

No, I do not think so.

Regards,
Radu

[SSC]

Hi Radu,

You could call:

Code: Select all

ro.sync.exml.workspace.api.PluginWorkspaceProvider.getPluginWorkspace().saveGlobalOptions()

on your pre-shutdown hook.

This would be an option.
This would force me to build an Eclipse ExtensionPoint, which will be used in our Oxygen integration plugin to invoke the "saveGlobalOptions", but it would work.

ro.sync.ecss.extensions.api.OptionsStorage.setOption(String, String)

to save the changes. Maybe our implementation of this OptionsStorage.setOption API could also synchronize with the Eclipse preferences store. I'm reluctant to do this because it might induce some lag, our entire options would need to be saved to XML and this might take a second or so. So adding that extra API for you would be my preferred choice.

But you could also consider to build an Adapter for the Eclipse Preferences, so that the Adapter can be used like you also would use your xml preferences, but internally splits up your xml and stores it to several diffrent IPreferenceStore keys in order to avoid the lag.
So the Adapter could encapsulate the Eclipse Preference settings internally and can be used as if it would be your usual xml preference. At the first look it seems that your OptionsStorage is somehow similar to the Eclipse Preferences(ChangeListener, Getter and Setter with key and value pairs...OptionsStorage) so that I could imagine an OptionsStorageAdapter, which internally uses the Eclipse Preference API.

This would have the benefit that your customers would be able to use the Eclipse Preference API, which would be working internally in the suggested Adapter. I can imagine that some day we or maybe an other customer likes to change some of your preferences by code. The Adapter suggestion would easily make this possible.
This would be my preferred choise and I guess also your´s, if you had time for this.

But currently we could live with both solutions.

If you have questions concerning the second approach I suggested, you are pretty welcome to ask.

Best regards,

Simon

[Radu]

Hi Simon,

We will add API in the upcoming 15.2 for:

ro.sync.exml.workspace.api.PluginWorkspace.saveGlobalOptions()

But you could also consider to build an Adapter for the Eclipse Preferences, so that the Adapter can be used like you also would use your xml preferences, but internally splits up your xml and stores it to several diffrent IPreferenceStore keys in order to avoid the lag.
So the Adapter could encapsulate the Eclipse Preference settings internally and can be used as if it would be your usual xml preference. At the first look it seems that your OptionsStorage is somehow similar to the Eclipse Preferences(ChangeListener, Getter and Setter with key and value pairs...OptionsStorage) so that I could imagine an OptionsStorageAdapter, which internally uses the Eclipse Preference API.

Your analysis is correct. I agree with you, right now we are not working as we should with the Eclipse Preference Store. We will consider this for a future version.
We have some complex objects which hold various settings and can be serialized to XML (you can see the hierarchy for the ro.sync.options.PersistentObject interface in the Oxygen main JAR library). So this kind of objects would need to be serialized to XML and saved as a string each time they are set and the opposite done to them when they are obtained. This would be the main difficulty, the fact that such objects would need to be saved to XML and back each time they are accessed or modified.

Regards,
Radu

[Radu]

Hi Simon,

Oxygen 15.2 was released so you can try out the new API.

Regards,
Radu