extended if() functionality

RE: extended if() functionality

caroline.brautigan — Tue, 31 Oct 2023 15:28:08 GMT

If you do need to check a value against multiple conditions, a good alternative to nested if() statements (or using this undocumented behavior in a single if()) is the a!match() function.

https://docs.appian.com/suite/help/23.3/fnc_logical_match.html

Here's an example that shows using it to check multiple conditions: https://docs.appian.com/suite/help/23.3/fnc_logical_match.html#using-the-equals,-whentrue,-and-then-parameters

RE: extended if() functionality

Stewart Burchell — Tue, 31 Oct 2023 11:28:49 GMT

Hah! The first (Zen) rule of Appian is "Developing Appian requires great peace of mind"...

RE: extended if() functionality

davidkessler — Tue, 31 Oct 2023 11:26:22 GMT

Thanks,Stewart - your detail and Stefan's summary hit my brain lock from both sides! Thank you so much. (Also, sleep helps.)

RE: extended if() functionality

davidkessler — Tue, 31 Oct 2023 11:10:19 GMT

Thanks for looking. Yes, in the morning this does make perfect sense!

RE: extended if() functionality

Stewart Burchell — Tue, 31 Oct 2023 09:55:59 GMT

To explain the syntax of the example expression you've provided...it does conform to the documented pattern - it has a condition, and returns a valueIfTrue and a valueIfFalse.

Your example is a bit more complex in the that the returned values are themselves not fixed values but are evaluated at runtime. If you took each of the posisble values to be returned and evaluated them in isolation they'd return wither true or false. That is:

local!level= cons!APPL_LVL_THIS is either true or false

and

local!level = cons!APPL_LVL_THAT is either true or false

...but only one of them will be evaluated/returned depending on whether local!status = cons!APPL_STS_OFF returns true or false.

So there's nothing wrong with the syntax of the your if() statement, other than it's hard to read and (probably) hard to debug. The code could have local! variables set to the individual results of those evaluations and used in your if() statement, like this:

local!isLevelThis: local!level= cons!APPL_LVL_THIS,

local!isLevelThat: local!level= cons!APPL_LVL_THAT,

showWhen: if(
              local!status = cons!APPL_STS_OFF,
              local!isLevelThis,
              local!isLevelThat
            )

I would find that easier to read/maintain that the example you provided but it is more verbose and does have the (probably immaterial) overhead of evaluating both values when only one is going to be returned.

By extension you could even code it like this:

local!isLevelThis: local!level= cons!APPL_LVL_THIS,

local!isLevelThat: local!level= cons!APPL_LVL_THAT,

local!isStatusOff: local!status = cons!APPL_STS_OFF,

showWhen: if(
              local!isStatusOff,
              local!isLevelThis,
              local!isLevelThat
            )

which is even easier to read and debug imo. I'm sure others will wade in with their opinions...

RE: extended if() functionality

Stefan Helzle — Tue, 31 Oct 2023 07:12:15 GMT

There is an edge case in the internal implementation which, theoretically, allows you to put multiple conditions into an if(). But this again can lead to more edge cases depending on which other values you use.

So, from my perspective, this is pretty simple. ONE if() takes exactly ONE condition!