View Configurations are stored in an Attribute Resource
Task Specifications are to be stored within a Project
A Task can have a set of “Styles” associated with it.
Styles can refer to Views
The problem is that Tasks live outside of any Attribute Resource so storing Views solely within an Attribute Resource is now potentially problematic.
Possible Solutions
Maintain View Configuration Storage in the Attribute Resource
In this approach, if a style refers to a View, then search all of the Attribute Resources found in the task for the View. This is the simplest approach though maybe not the most conceptually clean design. It would allow Attribute SMTK/SBT files to loaded into ModelBuilder without the need of loading in Projects.
Move the View Configurations into the View Manager
The View Manager currently stored all View generating factory functions and could be extended to also hold the View Configuration information as well. The problem in this case is View name collision. Two different Attribute Resources or Projects, could have View Configurations with the same name. This approach could result in one Attribute Resource / Project redefining the View Configuration of another unless care is taken to scope the names in some way.
Move View Configurations into the Project
Might be the cleanest approach conceptually, but the complication would be we would still need to support the current approach of have Attribute Resources also storing the View Configuration information as well.
I favor the last option (“move view configurations into the project”) because projects already access that data.
Projects, at least the ones that I work with (ace3p, cmb-2d, truchas), are hard-coded to one attribute template and, therefore, already load view information as part of creating attribute resources. In short, there is no need to “move” anything, other than possibly reorganizing our .sbt files so that the <views> element is partitioned in a separate file by itself.
Regarding “name collision” issues – they get resolved as part of implementing the template files for each project.
Side note: any “more generic” project would seem to require developing some kind of view configuration namespace feature, which I would not favor any time soon.
Side note: how projects should provide view information to the task system might be worth some discussion too. The easiest approach might be for projects to load the template to an internal (memory only) resource and pass its view dictionary when initializing tasks.
I found a complication related to this discussion. In SMTK’s qtGroupView and qtAttributeView both modify their View Configurations in order to remember which was the Current Tab and Current Attribute selected. This was to allow the UI to be restored when the attribute resource is reloaded.
Since the second and third approaches assume that the View Configuration is read only, this does make those approaches a bit more difficult. We would need to find somewhere else to store this information.