You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remove ManagerInterface.entityDisplayName, and replace with a DisplayName trait in MediaCreation.
Why
Now we have a composable traits system, that allows a host to express the entity data they need, in a concise (and reflectable form, via managementPolicy), making the entity name a first-class concept has several flaws:
It requires an additional API call to service, which can add non-trivial work.
In many situations where it would be called, a resolve call would also be made to provide other information.
It prohibits the addition of additional fields, eg, providing a shot name and a long name (maybe for UI + tooltip).
Fewer API methods to maintain.
By making it a trait, we can hopefully reduce the total number of API calls, and add more flexibility as to how this may need to evolve over time (It's also one less method to maintain).
Potential downsides:
Another trait to consider in resolve adds to implementation complexity.
Less discoverable.
The implementation of entityDisplayName could be individually optimized.
The text was updated successfully, but these errors were encountered:
This is better served by a resolvable trait to reduce API calls and
allow industry specific flexiblity.
ClosesOpenAssetIO#837
Signed-off-by: Tom Cowland <tom@foundry.com>
This is better served by a resolvable trait to reduce API calls and
allow industry specific flexiblity.
ClosesOpenAssetIO#837
Signed-off-by: Tom Cowland <tom@foundry.com>
foundrytom
added a commit
to foundrytom/OpenAssetIO
that referenced
this issue
Apr 4, 2023
This is better served by a resolvable trait to reduce API calls and
allow industry specific flexiblity.
ClosesOpenAssetIO#837
Signed-off-by: Tom Cowland <tom@foundry.com>
What
Remove
ManagerInterface.entityDisplayName
, and replace with aDisplayName
trait in MediaCreation.Why
Now we have a composable traits system, that allows a host to express the entity data they need, in a concise (and reflectable form, via
managementPolicy
), making the entity name a first-class concept has several flaws:resolve
call would also be made to provide other information.By making it a trait, we can hopefully reduce the total number of API calls, and add more flexibility as to how this may need to evolve over time (It's also one less method to maintain).
Potential downsides:
resolve
adds to implementation complexity.entityDisplayName
could be individually optimized.The text was updated successfully, but these errors were encountered: