“Computed attributes” are attributes of a
StoreObject which are somehow derived by plugins. The platform provides relatively low-level building blocks for plugins to implement these automatic modifications.
Rules for implementing computed attributes
You must implement computed attributes carefully.
- Apply a read-only restriction to prevent users from being able to edit attributes which would then be immediately overwritten
- Never modify attributes that the user can edit.
- Be careful to avoid reordering attributes.
- Think about permissions, as the active user will vary, and so will object visibility for queries. You will probably need to use
O.withoutPermissionEnforcement()and carefully consider what information will be revealed. Ideally, only set attributes which link to objects visible to everyone.
Ideally, carefully written generic plugins should implement computed attributes, and application specific plugins should only use those common implementations.
Implementing computed attributes
The hComputeAttributes hook enables a plugin to modify the attributes of an object before it is committed, or the platform makes decisions based on the attributes of mutable objects.
Apply a read-only restriction in the normal manner.
Mutable store objects
Most of the time, your code won’t have to worry about computed attributes. However, if you’re working with mutable StoreObjects, you may need to explicitly compute the attributes before using them.
Where it is necessary to have up-to-date computed attributes, call
computeAttributesIfRequired() before accessing them. This method is efficient and will work on mutable and non-mutable store objects, so you can call it as a precaution before all accesses.