Specialist article for working with property naming in expressions (Gizmo): syntax for dedicated use with lookups, an overview of loose name matching, dot and bracket notation
Reserved syntax for referencing properties in lookup tables
When working with lookups reserved syntax is required. In this example:
There is an association made between the lookup table AreaOne and the property Area. This then shows the available properties from the lookup table in the form:
Area: Revenue
In expressions, the way to reference these values is
node['{associative_propertyname}: {property_referenced_from_lookup}']
So from the example, to read the value associated with the property Revenue in the lookup table referenced via the Area property, the correct syntax is
node['Area: Revenue']
Loose Name Matching in Properties
This section originally arose because of a problem encountered with using a dash or hyphen to create a Total Compensation field, but see here for further context
There are potential problems associated with a property named:
HQ-Reimbursement
OrgVue in its expression calculations will interpret a '-' as a minus used within "dot notation", so a null value would be returned from the expression
node.HQ-Reimbursement
... based on the inability to resolve the expression "HQ minus Reimbursement".
If that part of the expression was altered so that it reads (say)
node.HQ_Reimbursement
then the calculation should work correctly. For completeness, it is possible to use non-dot notation and refer to
node['HQ-Reimbursement']
but as a matter of best practice, we would advise against including hyphens i.e. '-' in key names. (You should also avoid use of either the full stop or comma characters - "." or ",".)
Note: OrgVue's enhanced capabilities allows you to access a property via a loose name match, so even though the key here is HQ-Reimbursement, we can access it via any number of different forms:
node.HQ_Reimbursement
node.HQReimbursement
node.hqReimbursement
Best practice would be to use and underscore (_) where it is desired to have separators between words in property keys, and avoid spaces in property keys.
Careful - Loose Name Matching in Properties
There is a possible negative side effect - which can readily be avoided - of loose name matching in properties in that it is possible to create individual properties:
Which are indistinguishable in expressions as the following
node.clientstatus
node.client_status
could refer to either property given OrgVue expressions loose naming functionility
OrgVue will display an error if a display name is repeated in a given dataset (in the example, an extra space has been added between the two words) but there is no corresponding warning about keys which 'become' identical via the loose naming protocol.
Comments