Xplan Quick Xplain
The ternary operator: all in one conditioning
‘title’ if goodtitle==True else ‘bad title’
Explicitly elucidating some implicity.
In some of the articles on this blog, we’ve been using one line conditional statements – for example this article – but we haven’t actually drawn attention to them or explained them yet.
This quick xplain takes a look at exactly what they are, how they work and when they can be good.
Ternary Operator: aka single line conditioning, conditional expressions et al
Ternary operators are common in many programming languages. In the simplest terms they are just a way of conditioning a statement all in one (often on one line) rather than partitioning it into individual if/else conditions.
The word ternary means composed of three parts, and is a way of saying:
if has a preferred name then output preferred name else output first name
You have likely seen, and written, if/else conditioning like this:
In the above we’re essentially saying, ‘if client has a preferred name assign that to our variable else just use the clients first name’. NB: if you’re unfamiliar with variables check out this article.
As a conditional expression or ternary operator it could be written as:
<:let clientName=str($client.preferred_name) if $client.preferred_name else str($client.first_name):>
You can see both of the ways above are achieving the same thing, the only difference is how.
The only hard and fast rules are
- you always need some evaluating conditioning (if) and an alternative (else);
- You’re evaluating condition (if) can have a range of conditions attached to it, eg if $client.is_individual and $client.preferred_name else …
In general though just keep in mind if and else.
The good news is, else can be a null or blank result, eg
<:=item.amount.value if item.amount.value else '':>
<:=item.amount.value if item.amount.value else None:>
The above will show the item amount only if there is one, else nothing will appear. The above is purely for example, with dollar amounts you may be better off taking advantage of the additional currency arguments.
Chaining and multiple conditions
You aren’t limited to just individual if and else statements, you can chain multiple if’s together, like this:
<:=$client.preferred_name if $client.is_individual and $client.preferred_name else $client.first_name if $client.is_individual else $client.superfund_name if $client.is_superfund else $client.trust_name if $client.is_trust else $client.company_name if $client.is_company else $client.partnership_name if $client.is_partnership else ‘’:>
You will also note that you can have multiple conditions for each if statement. In the example above the preferred name needs the client to be an individual and have a preferred name.
Even though you can do this, it doesn’t necessarily mean you should. A lot of people would likely find the example above difficult to read, unnecessary and stylistically poor.
So the ability to additional conditions with and or in your conditioning is good, but take care not to unnecessarily overchain your code just to get it all in the one expression – at the expense of readability and ease.
With just about everything, there are pros and cons.
You can imagine that depending on the data and the usage, this has the potential to make your coding or templates more difficult to read, so exercise and use with caution.
Always keep readability and ease in mind.
Despite the caution and warning, there are simple instances where this fits in well with xmerge and templates. For assigning the clientName variable earlier it works well and you will have seen it used in our examples using the asset group:
About this example:
- a lot of advisers capture further details about a clients asset, eg what the car actually is rather than just the type of asset ‘Motor Vehicle’ and this descriptive data is captured in the ‘desc’ field of the asset group;
- If you are taking the time to capture this more personalised data (and the client is taking the time to provide it), then it makes sense to output that in many cases
- But there are plenty of advisers and sometimes historical client data, where that description isn’t captured so we need to rely on the type eg ‘Motor vehicle’
- The above allows us to easily cater for both instances without having to further increase the length of coding in the table with partitioned if and else statements.