526
edits
Changes
no edit summary
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 always encapsulate it within double quotes.
== In Template Formulas ==
'''Problem 1''':
''@level1.name@=@level1.owner.firstname@ @level1.owner.lastname@;''
Reason:
'''Problem 2''':
''@level1.name@='@level1.owner.firstname@ @level1.owner.lastname@';''
Reason:
Solution:
''@level1.name@="@level1.owner.firstname@ @level1.owner.lastname@";''
Always use double quotes around strings to be safe.
'''Problem 1''':
''frm.cf_@customfield.id@.value="";''
Reason:
In some cases where the field value is null, the variable processor will not replace the variable with blank and you will see ''frm.cf_@customfield.id@.value '' on the page. This will break this particular script and hence any subsequent script functions that follow afterwards on the page.
Solution:
''document.getElementById("cf_@customfield.id@");''
'''Problem 2''':
''var oppid=@opportunityid@;''
Reason:
Solution:
''var oppid="@opportunityid@";''
== In Visibility Conditions ==
'''Problem 1''':
''@opportunityid@>0''
Reason:
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.
Solution:
''"@opportunityid@"*1>0''
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.
'''Problem 1''':
''@ReportProperty(12345,recordcount)@ + @custom number@''
Reason:
Solution:
''"@ReportProperty(12345,recordcount)@"*1 + "@custom number@"*1''
The ''*1 '' is used to explicitly cast the result into a numeric value. This is needed in the case so that perhaps , 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.
'''Problem 2''':
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.
==See Also==* [[sslogic]]* [[sscalculation]]* [[inRole]] [[Category:Chin’s MusingsExpert Tips and Tricks]] [[Category:Variables]][[Category:Chin’s Musings]]
