...
You will probably also find it useful informative to install the pre-registered logging ruleset, and enable logging in the "Logging" tab.
The finally step in preparing your pico for use as the "back end" of the single page application is to create a channel for each timekeeper. Do this in the "Channels" tab.
...
and similarly for other timekeepers. Having a separate ECI for each timekeeper allows you to revoke access to the SPA for one timekeeper while allowing others to continue using it.
The Pico Ruleset
The ruleset shares (line 3) the function entries
(defined in lines 6-8), which simply returns the values of an entity variable named ent:entries
which will be maintained as a KRL map.
...
Rule timing_finished
(lines 31-40) selects when the event with domain timing
and type finished
occurs, provided it has an attribute number
matching the regular expression in line 32. If it does, the rule is selected with ordinal_string
set to the number. In the rule prelude, a normalized key
is built from the ordinal value. If there is already a timing with that key
, the rule fires, performing no action, and in its fired
postlude sets (to the current time) an attribute time_in
on the map for that timing.
In the "Rulesets" tab for the pico, you can check the box beside the timing_tracker
ruleset to see its entity variable. The value might look something like this (lightly edited for readability):
Code Block |
---|
ent:timings=
{"N1": {"ordinal":1,"number":"n1","name":"Nick Angell","time_out":"2017-04-26T22:35:48.446Z","time_in":"2017-04-26T22:39:47.998Z"},
"N2": {"ordinal":2,"number":"n2","name":"Connor Grimm","time_out":"2017-04-26T22:36:12.665Z"}
} |