Hints and tips on property naming and property 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 there is reserved syntax required.  In this example:

Lookup_-_syntax.PNG

There is an association made association 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.

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:

Client-status.PNG

Client_Statusx2.png

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.

 

 

 

 

 

 

 

 

Have more questions? Submit a request

Comments