Currently attribute::Item is not considered a component to an Attribute Resource (only attribute::Attribute is derived from resource::Component). This topic is focused on presenting potential benefits of changing the design as well as attempting to scope out what code changes this would entail.
Potential Benefits
- Items could be specified/returned w/r Operations
- Reference Items would be explicitly specified in a Resource Link making lookup and conflict resolution easier
- Items could have properties
- Items could be targeted by Reference Items
- Items could be found by UUID
- In the case of supporting active categories, if the resource has a map of all items it could easily traverse it to activate/deactivate Reference Items based on categories.
Potential Coding Tasks
Resource Link Usage Changes
- All of the current code that deals with Resources Links at the Attribute Level would need to be pushed down to the Reference Item Level. This could in theory make things cleaner since right now Reference Item has to manipulate the links through its Attribute.
Attribute Resource Changes
- Need to update Query grammar to include Items and their types (and values??)
- Probably needs to have a map of UUIDS to Items
- Deleting Items will now involve the resource
- Items will have direct access to the resource instead of having to go through its attribute/parent item
Additional I/O support (XML and JSON)
- Need to store properties on the Items - This is probably easy for JSON since the property system already supports this. Not too sure about XML.
- Need to store the UUID (not too much of an issue though the XML form probably needs to support the case of Items w/o UUIDs - when attributes are being hand written)
- Probably don’t need to change the format version
Attribute Utility Changes
- Find associatable objects will need to include items
QT GUI Changes
- qtReference Item will probably need some slight changes.