Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Explicit events are raised in the rule postlude with a raise statement. You can raise explicit events from a postlude like so:

raise <domain> event <expr> [for <expr>] [with <modifier_clause> | attributes <expr>] 

The event <domain> is can be one of

  • explicit
  • http
  • system
  • notification
  • pds
  • error

The event name is given by the <expr>. The expression is evaluated and the resulting string is used as the event name.

The modifier clause allows the developer to add event parameters to the explicit event. The right side of the individual bindings in the with clause can be any KRL expression. The modifier clause takes the following form:

with <var> = <expr> [and <var> = <expr>]* 

Any variable in a modifier clause is used (with its associated value) as an event parameter.  

The following example illustrates this

raise explicit event foo for "a16x48"
with a = "hello"
and b = 4 + x;

The attributes clause also allows the developer to add event attributes to the explicit event, but they are calculated. The expression that follows the attributes key work must evaluate to a map. The keys and values in the map will be used as event attributes. 

You can use a modifier clause or an attributes clause, but not both. 

What Rulesets See an Explicit Event?

In the Sky API, explicit events will be raised to any ruleset that an entity has installed. 

In the Blue API, 

The for clause is optional.

 

If it's missing, the event will be raised within the current rule set. The for clause is followed by an expression that is evaluated to determine which rule sets should see the event. The result of the expression should be either a string or an array of strings. The strings should contain a single rule set IDs.Adding for <expr> raises the event in the named ruleset. The default is the current ruleset. The result must be a string, giving the target ruleset ID or an array of target rulesets. A target ruleset ID has the form <rid[.<ver>]> where the optional version may be the keyword "prod" for the production ruleset or a version number for the explicit version. If the version is unspecified, the system will match the target version to the version of the current ruleset.

Like any other postlude statement, explicit events can be guarded:

raise explicit event foo
with a = "hello"
and b = 4 + x
if (flipper eq "two");

The event in the preceding example will only be raised if the variable flipper has the value "two".

Explicit events allow KRL programmers to chain rules together. Rule chaining is good for modularization, error handling, preprocessing, and abstraction as you can see in the Examples

  • No labels