... | ... | @@ -55,21 +55,15 @@ The base class for all resources modeled in SMTK would contain the following inf |
|
|
|
|
|
* URL - where is the resource currently located
|
|
|
* UUID - some unique identifier so if a resource's URL was changed externally there is still some way of determining if this is the correct resource
|
|
|
* Type - what type of resource this is (initially I was thinking this would be a string so we can dynamically extend the types of resources - currently we have geometric model, mesh, and attribute
|
|
|
* Meta Data - information (probably in the form of a key,value dictionary
|
|
|
* For example we could have subgroup information for geometry models (discrete, oce, polygon)
|
|
|
* Roles - what role this represents: Coastline, Car, Wind-tunnel, etc..
|
|
|
* Versioning - something to indicate the resource has been modified since it was last saved
|
|
|
* Versioning - history of saved versions of the resource
|
|
|
* Component Structure - something that describes the parts of the resource, for example:
|
|
|
* Attribute Resources - attribute, definition
|
|
|
* Geometric Models - vertices, edges, faces, volumes, aux geometry, component
|
|
|
* Meshes - Mesh Sets, Data Set (i.e. simulation field values)
|
|
|
* Been Modified - indicates that the resource has been modified since it was last saved
|
|
|
|
|
|
`john> The distinction between "Versioning" and "Been Modified" is not clear. Is one of them a bit/flag indicating that the model has changed in the current session? And the other a digest of the history of changes using, for example, the list of UUIDs as was discussed recently?`
|
|
|
|
|
|
`bob - Yes`
|
|
|
|
|
|
* Been Modified - indicates that the resource has been modified since it was last saved. This would be represented as a simple flag that can be set and cleared
|
|
|
* Resource Links - a set of resources that this resource references - Note that this does not mean that these resources must be loaded in prior to this resource being load into memory
|
|
|
* (Maybe) - a mapping between the component structure and the relevant workflow. For example in a surface water problem a vertex might be a hard point, an edge could be a coastline, and a face a water area.
|
|
|
* Resource Manager - this can be NULL meaning that the resource is not being managed and is up to the application to take care of it
|
... | ... | @@ -79,6 +73,8 @@ The base class for all resources modeled in SMTK would contain the following inf |
|
|
|
|
|
Note that all resources would be modeled as shared pointers
|
|
|
|
|
|
Also note that there is no longer a type() method to indicate what type of resource the resource is. The idea behind this decision is that dynamic casting would be used to determine if a resource is of a specific type
|
|
|
|
|
|
#### Derived Resource Classes
|
|
|
The set of resource classes would include:
|
|
|
|
... | ... | @@ -87,18 +83,18 @@ The set of resource classes would include: |
|
|
* Attribute Collection - what the current Attribute System is in SMTK 1.x
|
|
|
|
|
|
### Resource Component Base Class
|
|
|
A Resource component is a part of a resource and relates to the component structure of the resource so for example a resource component of a geometric model could be a vertex, edge, face, volume, aux geometry, etc.. In the case of a Mesh Collection, the only resource component is a Mesh Set. Likewise for an Attribute Collection, the only component is an Attribute.
|
|
|
A Resource component is a part of a resource and relates to the component structure of the resource so for example a resource component of a geometric model could be a vertex, edge, face, volume, aux geometry, etc.. In the case of a Mesh Collection, resource components could include PointSets, CellSets(including their dimension) and Fields. Likewise for an Attribute Collection, the only component is an Attribute.
|
|
|
|
|
|
All resource components would consist of the following:
|
|
|
|
|
|
* UUID
|
|
|
* Type
|
|
|
* Meta Data
|
|
|
* Roles
|
|
|
* Versioning
|
|
|
* Owning Resource
|
|
|
|
|
|
As with Resources, Components would be modeled as shared pointers.
|
|
|
Note that once again there is no type() method. The reason is that each derived resource has its own interpretation of what the type represents. For example, the Model Resource interprets the type as a set of bits that represent different aspects of the model entity
|
|
|
|
|
|
#### Derived Resource Component Classes
|
|
|
Based on the current types of resources the derived classes would be:
|
... | ... | @@ -119,3 +115,9 @@ The Manager is responsible for managing a set of Resources and would include the |
|
|
* Ability to register creation functions/operators to the manager
|
|
|
* Is a Resource currently loaded?
|
|
|
* Does it manage a specific Resource?
|
|
|
|
|
|
## Changes to the Attribute System
|
|
|
* Rename System to Collection to be more consistent
|
|
|
* Add ResourceComponentItem and ResourceComponentItemDefinition classes
|
|
|
* The existing Model and Mesh Entity Item and Definition classes would derive from these
|
|
|
* Change Model Association to become ResourceComponentAssociation and use the above new structure |
|
|
\ No newline at end of file |