Details
-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
Description
Food for thought:
Scenario:
1) A resource that historically has child resources of child type 'property', where children of that type have a single attribute 'value' each child is really just an entry in a map.
2) A better API would be to have a 'properties' attribute in the parent, defined using MapAttributeDefinition.
It would be good to be able to switch to the map attribute and deprecate the child resources. But for compatibility reasons the child resources can't just be dropped. And that makes this kind of change painful. If the extension API could provide some helpers that would be good. For example:
a) read-attribute handler for the map attribute that reads the child resources.
b) write-attribute handler for the map attribute that diffs the map and adds add/remove/write-attribute steps for the child resources.
c) Transformer logic for legacy domain mode slaves that diffs the map and transforms the op to a composite made up of add/remove/write-attribute ops.
An alternative to a) and b) above is to make the new map attribute the authoritative store of data and then update the child resources to work with it (the transformer discussed in c) would still be needed):
x) the handlers for child resource add or write-attribute ops just add a map-put step against the parent resource
y) the handler for the child resource remove op just adds a map-remove step against the parent resource
z) A specialized resource type would be needed for the parent resource, one that understands how to read the map attribute from its own model and represent its entries as child resources.
Perhaps both sets of functionality would be useful.