New configuration mechanism #113
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The static layer of indirection to getting preferences allows for the future refactoring of the existing JmriPreferencesProvider and JmriConfigurationProvider classes to make them compatible with the NetBeans Project API while isolating the potential changes.
If we need to provide specific conversions between other types of JDOM<->W3C objects, each conversion would need a toJDOM<Object> and toW3C<Object> method. Refactoring this now makes doing that easier in the future.
Add load method to AdapterXml API that is shared/private element aware.
Returns classes instead of class names when needing class information. Add ability to provide list of classes that this class is a ServiceProvider for, to allow lookups in the InstanceManager for specific subclasses of PreferencesProvider to work without having a PreferencesProvider register itself in the InstanceManager.
No longer limit services providable by a PreferencesProvider (PP) to services that do not extend PP (this allows a PP to be registered as providing other services or abstract classes).
Note that this new implementation passes on some configuration to the existing older default implementation. Classes and interfaces that provided direct access to the default implementation no longer do so.
This implementation is also a manager for ConnectionConfig (CC) objects, although all CC objects are jointly registered using the old (via the ConfigureManager and new (via the ConnectionConfigManager (CCM)) mechanisms. CC object registered with the CCM are retained past a save action in the TabbedPreferences, while the old registry is cleared and not rebuilt (this has been confirmed to be true as far back as 3.8, so I think this has always been true). The logic for really adding and removing CCs from the CCM has not been wired into the relevant PreferencesPanel yet. All of the ConnectionConfigXml (CCX) objects have been refactored to call a method of the CCX abstract object, so a single method contains the register code, so future changes to registration are mostly in a single source.
…t ConnectionConfigs.
This prevents unit tests from failing but is not expected to be encountered in use.
Continue to register/deregister ConnectionConfigs in the InstanceManager so that ProfileConfig.xml continues to be saved.
Also don’t append connections to existing element, but replace old connections element with all new element.
Add register method to ConnectionConfig and move registration from the ConnectionConfigXml to ConnectionConfig. This enables registration of a ConnectionConfig at points other than loading a configuration. The default implementation currently registers the ConnectionConfig with both the InstanceManager and the ConnectionConfigManager.
Previously new connections were not registered until after JMRI restarted.
A side effect of these changes is that the ManagerDefaultsSelector had to be refactored from an enforced singleton (using the instance variable) to an object managed by the InstanceManager.
Allow the legacy ConfigManager to handle this without any action on the new ConfigManager unless the file is ProfileConfig.xml
Clean one-liner for returning false instead of null if the profile has not been initialized.
PreferencesProviders can throw an exception on initialization that will be displayed to a user. If a PreferencesProvider is initialized multiple times, only the first exception will be displayed (displaying the errors is not yet implemented).
|
Current state:
|
The default fontSize is 0, so allow it.
Works around strange edge case where, when a profile is migrated from using ProfileConfig.xml to profile/profile.xml, ConnectionConfigs would not list correctly when getting the instance list from the ConfigureManager until after JMRI is restarted. This work around changes queries against the ConfigureManager’s instance list to using the ConnectionConfigManager to get the list of ConnectionConfigs.
|
Of note, this still saves the current and correct profile:ProfileConfig.xml and profile:profile.properties files for backwards compatibility with JMRI 4.0 and earlier. |
|
The on-disk layout of this configuration mechanism is described in #69 |
|
There are some other issues with this: With existing profiles where "User Files Location" is non-default and The selected preferred programmer format is ignored and also not displayed |
|
One of the profiles I tested I was able to reset Roster Location, but |
4 tasks
bobjacobsen
pushed a commit
to bobjacobsen/JMRI
that referenced
this pull request
Oct 5, 2017
Update TechRoadMap.shtml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change the configuration mechanism to use files within profile:profile instead of profile:ProfileConfig.xml
This mechanism is engineered to support #69, but the individual preferences panels / managers still do not handler per-node preferences.