XPLAN XMERGE

The third dimension of boolean fields

Boolean fields are generally considered to only have two states: ‘True’ or ‘False’. Depending on what you are trying to achieve, taking advantage of the null (none) state can be handy.

1. True: value = 1, text = Yes
2. False: value = 0, text = No
3. None: value=None, text=None

This can be good because often clients may consider data not entered to be ‘Not disclosed’ or ‘not provided’ – options which a Boolean field cannot include in its binary (Yes/No) drop down. By considering the third state of None we can get our client their not disclosed option without having to consider alternatives such as using a new field – which has implications for existing data and may move us away from using standard system fields.

Boolean Coding

Historically if a Boolean field didn’t have a value assigned it would produce a blank result in your merge document.  Instead we could utilise coding like this:

<:if str($client.valueOf(‘will_exists’)) in [‘0′,’1’]:>
<:=$client.will_exists.text:>
<:else:>
Not disclosed
<:end:>

With the above coding we will always get “Yes/No/Not Disclosed” (or whatever the client wants to call this).

There may be instances where you want to condition all 3 states explicitly, in which case we might use:

<:if str($client.valueOf(‘will_exists’)) in [‘0′,’1’]:>
<:if str($client.valueOf(‘will_exists’)) in [‘1’]:>
Yes
<:else:>
No
<:end:>
<:else:>
Not disclosed
<:end:>

Earlier, I said historically – that’s because these days in newer versions of Xplan Boolean fields will always return a result Yes/No/None or depending on how you’ve coded it 1,0,None. So there are no more blanks but chances are we still want to condition as ‘None’ doesn’t mean anything to a client or even staff members.