With KRL, it's often best to have separate rules to handle the "if...then" and "else" cases described in your question. That's simply because it's a rule language; you kind of have to change your way of thinking about the problem from the usual procedural way of doing it.
That said, Mike's suggestion to raise explicit events is usually the best way to solve the problem. Here's 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 easy enough to write two rules that are the same except that one has a not
in the if
statement and the other does not. That accomplishes the same purpose:
if (not ent:logged_in) then {
There is more documentation about the postlude (fired
and notfired
, for example), on Kynetx Docs. I also like the more extensive example that Mike wrote on Kynetx App A Day.