See the section called “Cloning the Variable List”.
What happens when a dataset cannot be resolved from the current datasources? Create a template datasetback with all of the variable info but which will never hold any data? All such datasetbacks might belong to a special datasource, except there could be collisions in the dataset name. Such a template dataset could have its own DataSetBack which does not belong to a DataSource, and which deletes itself when all of its references are gone. The complication would be that every call to DataSet::getDataSource() must check for a null return.
Is it time for a separate dataset template class?
Maybe no change is necessary? If no dataset can be resolved when applying a configuration to a plot, then that member of the DataSetSelection is left null, the DSS is not valid, and thus it is not added to the plot. I suppose the user can try again with the same config and a different datasource. The point is that once a DSS is added to a plot, all of the required datasets have been resolved and the DSS is valid. If a plot is created and none of the traces can be validated, then the plot will be empty. At that point, maybe the DSSW pops up automatically with the template selection and some feedback on which axes cannot be resolved and need to be selected manually. Definitely this option, and perhaps every option, implies some clear feedback to the user as to what got resolved from where.
The DSSW could be the place to provide that feedback. In the 'currently selected' panel at the bottom, which shows the current selections for each axis, show also an indication of whether the variable could be resolved as specified. In other words, open the DSSW with the 'template' DataSetSelection, so the user can see and adjust how each variable is mapped to a particular datasource. The DSSW can show other context information there which would be useful in adjusting the selection, such as the data times available in the current datasource and the datasource specifier.
Even if a variable list cannot be completely resolved, the list still needs to stay with the Plot. That way if the application of several traces from an existing configuration fails, the user can still go back one-by-one and fix each one by editing (replacing) them through the DSSW. Or when the user opens a new datasource against which unresolved variable templates can now be resolved, then the resolution can happen automatically. This discounts the option of not restoring variable lists which cannot be completely resolved, and instead favors the idea of template datasets which hold no data but can serve as placeholders in a plot configuration.
Whatever scheme is used for orphaned DataSets (datasets that cannot be resolved to a datasource) can work for closing a datasource. When a datasource is closed, it orphans all of its datasets. The orphan datasets become templates which hold no data, but which can be resolved to a new datasource when available. I guess this all comes down to needing a dataset notion distinct from datasources.
About Unresolved DataSet
Templates. There is some consensus that when the DataSet templates in
a Plot configuration cannot be completely resolved, then it's
reasonable to popup a window explaining what could not be
resolved and offering to open the DataSetSelectionWindow to resolve it. For
example, this could be a list of the traces whose DataSet
templates were not completely resolved, and for each unresolved
trace there is the option to cancel that trace or popup the
DataSetSelectionWindow on that trace. The popup would also offer a button to
cancel all of the unresolved traces. For
the moment, though, I decided the warning popup does not exclude
implementing some kind of orphan DataSet.
About Standard Configurations. One benefit to external configuration libraries, such as the database or web server on the plane, is that they can be used to update existing aeros installations. See the section called “Pulling Updated Configurations”. If a set of standard configurations evolves relevant for all aeros installations, then that set can be bundled with the distribution. However, more likely is that standard configuration sets will be tied to particular data, so that it makes more sense to package configurations with the data. For example, RAF configurations can be stored within netcdf files, or next to them, or on a web server. Likewise for ISS netcdf data.
About Inheriting Configurations.