extended if() functionality

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...

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...

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

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