In KRL, it is often better to have separate rules for handling the "if ... then" and "more" cases described in your question. It is simply because it is a language of rules; you seem to have to change your mindset about the problem using the usual procedural way of doing it.
However, Mike’s suggestion of raising explicit events is usually the best way to solve the problem. Here is an example:
ruleset a163x47 { meta { name "If-then-else" description << How to use explicit events to simulate if..then..else behavior in a ruleset. >> author "Steve Nay" logging off } dispatch { } global { } rule when_true { select when web pageview ".*" //Imagine we have an entity variable that tracks // whether the user is logged in or not if (ent:logged_in) then { notify("My app", "You are already logged in"); } notfired { //This is the equivalent of an else block; we're sending // control to another rule. raise explicit event not_logged_in; } } rule when_false { select when explicit not_logged_in notify("My app", "You are not logged in"); } }
In this simple example, it would also be simple enough to write two rules that are the same, except that if has a not operator and the other doesn't. This accomplishes the same goal:
if (not ent:logged_in) then {
There is more documentation on postlude ( fired and notfired , for example) at Kynetx Docs . I also like the more extensive example of what Mike wrote on Kynetx App A Day .
source share