One of the first Views that was created was the Instanced View which allowed the designer to specify a list of Attributes to be displayed. If the specified Attribute did not exist at the time the View was displayed, it would be created. This “feature” also required the designer to specify the Attribute’s Definition in addition to its type.
Though the View is commonly used in many workflows there are a couple drawbacks:
-
The attribute instantiation occurs (if needed) when the View is displayed which means if the View is never displayed those Attributes are never created. This can cause complications since the workflow can’t always depends on the Attributes existing. In fact some workflows have gone out of their way to traverse the View structure to make sure the Attributes in Instanced Views are created.
-
When the Instanced View does create Attributes, this caused the Attribute Resource which holds those Attributes to be marked modified. This can cause confusion for end users since simply clicking on a Tab suddenly marks their resource as modified due to this instantiation “side effect”.
Proposed Solution
-
Today, is very easy for the designer to simply add those “Instanced” Attributes to the Attribute Section of a template file. This removes the needs of the Instanced View’s auto instantiation mechanism.
-
Create a new View called AttributeList which would be identical in format to the current Instanced View with the exception that the designer would only need to specify the Attribute’s name and not also its type. If the named Attribute does not exist, the View would report an error instead of creating the Attribute.
-
Deprecate InstancedView - At the time the XML or JSON files are read in, the Attributes referred to in the View would be instanced if needed and a AttributeList View would be created instead. The class itself would be marked as deprecated and no longer automatically registered with the View Manager.