The Musings of Chin - Correct Variable Processor Use
This week from Chin, he covers the correct practices for using SmartSimple's powerful Variable Processor.
Let's learn about the proper use of SmartSimple's Variable Processor!
The Variable Processor is the functionality built into SmartSimple used to pre-process and dynamically replace various values throughout the system with context to the current user or the object being viewed. While the Variable Processor is a very powerful and useful tool, when carrying out any configuration one must understand the basics behind how it functions.
It is easy to make mistakes that lead to various degrees of undesired behaviour, and some of these self-imposed issues can actually be very subtle and hard to notice as well. The good news is that these issues are also easily avoided by keeping the following best practices in mind.
In general, any time that you retrieve a variable for use in a calculation, evaluation, or assignment to another field, you need to encapsulate it within double quotes.
In Template Formulas
When assigning a string value into a custom field, the string must be encapsulated within quotes. This example would cause an error on the server and nothing would be saved to @level1.name@.
Names with apostrophes will terminate the single quoted string (i.e. if my name is Chin O'Brien) this will cause an error on the server and nothing would be saved to @level1.name@.
Always use double quotes around strings to be safe.
In Browser Scripts
In some cases where the field value is null, the variable processor will not replace the variable with blank and you will see firstname.lastname@example.org@.value on the page. This will break this particular script and hence any subsequent script functions that follow afterwards on the page.
Again when the variable doesn't exist or is blank this script will break and all subsequent scripts as well.
In Visibility Conditions
When you create a new Level 1 it will look like the condition's working as you don't see the field, but in reality this will cause server errors as the @opportunityid@ is not replaced as that value does not yet exist for new Level 1s. An error will cause the visibility condition to always fail, which will lead to undesired behaviour.
Note: For this particular example, there is a check box setting within the custom field configuration that allows you to hide fields on new objects until the object is saved at least once.
@ReportProperty(12345,recordcount)@ + @custom number@
If either of the above values is blank or null, this will cause an error and will not work.
"@ReportProperty(12345,recordcount)@"*1 + "@custom number@"*1
The *1 is used to explicitly cast the result into a numeric value. This is needed so that, if your @custom number@ contains an alphabetic character, the *1 will convert it to a 0. If for some reason you use a @ReportProperty()@ that returns blank, ""*1 will also convert to a 0.
Not using quotes within @sslogic()@ or @sscalculation()@ conditions will also create errors but again you may be oblivious to them as the @sslogic()@ doesn't show up but this may appear to be correct for certain situations.
The following situations should be considered:
1) The .inRole variable will always return the values of true or false so there is no need to encapsulate this within double quotes (i.e. @me.inRole(Organization Contact)@).
2) When the variable value you are retrieving contains double quotes within itself you will need to escape these, or encapsulate the variable within single quotes if you are sure the variable value does not contain single quotes within.