External changes of preference values not possible

[finanzer]

Now the preference values will be read from storage everytime the method show() is called. That makes it impossible to change a value somewhere else in the application, because a new value will b overriden by storageHandler. Is it really usefull to read the values everytime when the dialog is shown? I think the values are already in memory and could be used directly.

[martinfrancois]

Thanks for your comment! During the implementation, we thought of PreferencesFX being the central and only place where these values would be influenced, hence why we didn't think of this. But of course you are absolutely right, we should introduce some kind of check and apply externally changed values without overriding them with the saved settings upon opening.
Also concerning reading the values every time the dialog is shown, this for sure isn't something that is necessary. Feel free to submit a PR to fix these issues!

[ghost]

A related item is StorageHandler imposes that implementations provide Preferences getPreferences(). This makes sense for a PreferencesBasedStorageHandler but does not make sense for an XmlStorageHandler where the backing store is Apache Commons XMLConfiguration, rather than a Preferences object.

Recommend updating the API to remove the following accessor method from the StorageHandler interface:

 Preferences getPreferences();

If needed, another interface, such as PreferencesStorageHandler, could extend from StorageHandler to offer any Preferences-specific definitions. Then PreferencesBasedStorageHandler could implement PreferencesStorageHandler, leaving StorageHandler with an API that doesn't "force" a particular storage mechanism implementation. (Likewise, clearPreferences could be renamed to clear to decouple the concrete concept of Preferences from the interface altogether.)

On that note, StorageHandler should be agnostic to UI settings as well. Currently, methods such as saveDividerPosition, loadDividerPosition, saveWindowWidth, loadWindowWidth, and so forth, all require the implementation to provide functionality for these methods. It would be more flexible to extract these into their own interface so that developers who don't care whether the PreferencesFX UI dialog persists its dimensions and layout need not implement such methods when creating their own implementation(s) of StorageHandler.