I want to implement logic similar to the following using triggers:
if ( A) {
output = dosomething(); // like run a connector function and get the ouput.
if ( <predicate related to the output> ) {
pass;
}
else {
pass;
}
} else {
pass;
}
Your code just does something if A and then pass in any case.
You could just put two triggers in a row. the first checks for A else pass.
The second check for output from the first (dosomething) and if so, it does something else.
Or you can use an if(@variable.b = 1, true, false) in an expression inside of an if/then clause…
So nesting is possible but most of the times not needed (and also in programming not always good practice).
Thanks for your reply. I want to invoke a connector function, which may return two different types of data, and I need to perform different operations depending on the type.
So in the first trigger clear the variable and call your connector.
Then use a second trigger to check the connector output and tacke action on this result.
… to be able to treat it as single block that does not require me to do a deep dive every single time some app logic needs to be revisited for whatever reason.
Here is an example of using an IF expression within trigger logic where I didn’t want to create another trigger with conditions based on whether the Barcode Parse 2 Variant was blank (as opposed to null), which would defeat my LINK function.
The unexpected result without this insertion was that the SKU(-Variant) Lookup displayed the SKU followed by “-” and nothing after the hyphen, which doesn’t work when we lookup disposition based on that SKU(-Variant) Lookup variable.
Triggers are always evaluated sequentially, with the first condition set (if/if-else) satisfied within each trigger being executed and the actions under that condition set being executed sequentially, potentially concluding with a transition (which escapes any subsequent triggers).