View nodes vs. domains
The "viewNode" and "domain" are common variables available to most rules and text keys as well. A number of platform tags allow targeting of other view or domain nodes as well. When should you favour one over the other? Below are some general rules to follow is this respect:
Setting values
Care should be taken when using domain nodes to set attribute values.
Often rules are associated with attribute view nodes that are triggered when the value is set or changed, as part of the "change" and "validate" rule scopes. Similarly a "change" event is fired, which may be caught by an ancestor view node. If the attribute value is set directly via the domain instead then these rules and events won’t be run or fired. Another case is attribute view nodes that is a group selector – if set via the domain instead then any changes that would apply to the view tree as a result of the group selection update will not occur.
One scenario that feels like an exception to this rule, but is in fact OK, are the setting of things like start dates or statuses on domains using the "activate" rule scope, especially for "Create" mode service instances. This tends to be OK since there aren’t typically any group selections or rules associated to these view nodes, in fact they often don’t even need to be in the view tree at all as they’re not displayed.
Validation
The “validate” rule scope
When it comes to validation logic, always ensure it is added using the “validate” rule scope, even if it is triggered by some other action.
When it comes to validation logic, always ensure it is added using the "validate" rule scope, even if it is triggered by some other action. The reason for this is validation is required when certain actions happen, such as attribute values changed, a repeater children added or removed, etc. but validation is also called at certain crucial points throughout the business service workflow, for example when the user wishes to submit the service. Keeping the validation rules within the "validate" scope ensures the validation will not be missed at these other important points also.
Don’t rely on the UI
This isn’t a rule just because it rhymes 🙂 The UI sometimes helps us out by not allowing certain things to happen. Like not entering too many digits into an attribute field that only allows 4 characters. Or not being able to add more directors that the configured maximum. But just because the UI offers this behaviour it does not mean the underlying validation doesn’t need to be configured.
The UI can be thought of as a convenience layer when it comes to enforcing behaviour, providing a cleaner user experience, but not to be relied on to be the last line of defence for upholding business rules or maintaining data integrity.
The reason the UI shouldn’t be relied on for enforcing business rules include the following:
- Functionality within our registry applications are often accessible via APIs which bypass the UI layer altogether
- The UI layer is not set in stone and can change
- Any client-side logic the UI layer relies on may be able to be bypassed by suitably technical users, or accidentally by novice ones 😉
For this reason always ensure you have configuration that meets any business requirements around validation even if partially or wholly covered by the UI. Belt and braces over the risk of being left without either 🙂
Group selectors
Group selectors offer a way to have different configuration be relevant based on a value selected within an attribute field. The litmus test for whether a group selector is appropriate is whether:
- the configuration is different based on the selected option i.e. certain configuration applies or doesn’t
- the values entered within child structures are independant. In other words the data which may relate to the same underlying information, should retain it’s values relating to the group selector attribute value
If the structure of the configuration is the same regardless of what value is selected and it’s just the properties of the configured items that changes, then rules are probably more suitable.
Group selectors are best when you want different config structures based on what’s selected, and/or any attribute/record data values managed separately. Rules tend to be cleaner if the structure is the same regardless of what’s selected but the view node properties are different i.e. visibility, read-only, etc.
Example scenarios
Say you have an attribute relating to a question like "Have you changed your name?" and if you answer yes, then you are required to add a new name. The new name (structure) only applies if you answer ‘yes’ to the name change question. This makes it a good candidate for a group selector.
If you have a question like "Is this director a registered individual?" and if you select ‘yes’ then you add their details via a search lookup, with their details only visible when populated, and displayed as read-only. If you answer ‘no’ however, you still enter the same details but in this case they’re all editable and need to be completed via manual entry. In each case, the structure of the details – for example the director’s name, address, etc. – remain the same and it’s just the mechanism and state (or properties) of the view nodes that differ in each case. This tends to make this a good candidate for using a rule (or rules) rather than a group selector.
