What you need is nested IF's (not IF.. ELSE If.. ELSE), which Aware does not directly support in the same rule.
Not supporting nested IF's, and the resulting necessary redundant/superfluous code which likely results in frequent duplicate evaluation of rules in many applications, I suspect, would become a performance issue if an Aware app was ever going to attempt to support thousands of concurrent users.
Nested IF's would be a worthwhile enhancement for consideration as a user sponsored enhancement, assuming Aware's architecture technically supports it.
Think how much less complicated and involved and shorter some of your rules would be if nested IF's were supported.. and how much 'cleaner' and tidier the code would be. And think how much less of a head flock they would be to check through and follow when you are examining them in order to ensure nothing unexpected is happening and that you have them structured for the most efficient execution.
Anyone reading this, leave a reply Post and comment accordingly if you would be interesting in finding out if a nested IF enhancement could be incorporated.
However, that being said, you can simulate nested IF's by using subprocesses (although having to call the subprocess rather than just launch straight into the nested IF is itself superfluous code), and if you name them appropriately AND using '_' at the beginning of their name repeated accordingly so as to simulate indents, then they appear in a logical hierarchy and it doesn't get too messy.
I also recommend putting all related pseudo nested IF's in one folder whose name would relate to the object and rule which calls them.
In your case you only need one nested IF series, ie. one level deep indent. And you need to concatenate incrementally.
Dynamic rule on the main object:
- The 4 OR Conditions remain as is
- Change the Actions to::
..Action 1: Zone.Name=Zone.Well [this is mandatory so no need to test for content for purposes of the final concatenated string]
..Action 2: RUN PROCESS <process name> [including 'RUN PROCESS' is optional, you can just call a process by stating its name]
'<process name>' rules, conditions and actions:
Rule 1:
IF ..Condition 1: Zone.Field IS DEFINED
THEN ..Action 1: Zone.Name=Zone.Name+' - '+Zone.Field
Rule 2:
IF ..Condition 1: Formation IS DEFINED
THEN ..Action 1: Zone.Name=Zone.Name+' - '+Zone.Formation
Rule 3:
IF ..Condition 1: Reservoir IS DEFINED
THEN ..Action 1: Zone.Name=Zone.Name+' - '+Zone.Reservoir
Although Zone.Well is mandatory, up until the user saves the form they could in theory change the other 3 and have Zone.Well empty, in which case the dynamic UI will show ' - ' at the beginning of the concatenation for Zone.Name.
Although Zone.Name cannot be saved with the ' - ' at the beginning because Zone.Well is mandatory, you could 'tidy' up this UI appearance by, in theory using another nested IF level subprocess to negate redundancy by testing Zone.Well for UNDEFINED first, and then calling a subprocess which doesn't include the ' - ', however this makes it overly complicated for the sake of negating minor redundancy.
BUT in a big system with a lot of users avoiding even the slightest bit of redundant code might materially impact performance of the system. But since this is client side evaluation, in this case it probably wouldn't matter.
Instead of using another nested IF level, you could incorporate ELSE If in the above 3 rules of '<process name>':
Rule 1:
IF Zone.Field IS DEFINED AND Zone.Name IS DEFINED
THEN Zone.Name=Zone.Name+' - '+Zone.Field
ELSE IF Zone.Field IS DEFINED AND Zone.Name IS UNDEFINED
THEN Zone.Name=Zone.Field
Rule 2:
IF Zone.Formation IS DEFINED AND Zone.Name IS DEFINED
THEN Zone.Name=Zone.Name+' - '+Zone.Formation
ELSE IF Zone.Formation IS DEFINED AND Zone.Name IS UNDEFINED
THEN Zone.Name=Zone.Formation
Rule 3:
IF Zone.Reservoir IS DEFINED AND Zone.Name IS DEFINED
THEN Zone.Name=Zone.Name+' - '+Zone.Reservoir
ELSE IF Zone.Reservoir IS DEFINED AND Zone.Name IS UNDEFINED
THEN Zone.Name=Zone.Reservoir
*OR*
or, you could forget about all the above and just have a whole heap of IF.. ELSE If.. checks evaluating all possible scenarios in each of 4 separate rules of the object (one rule for each possible changed attribute, with the multitude of IF.. ELSE.. if conditions and actions repeated in each). :mrgreen:
