Tips on property naming and referencing in expressions

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 dataset Area One 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 an 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.