-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New configuration mechanism #113
Conversation
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 |
Update TechRoadMap.shtml
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.