...
The rule creates the new child pico (shown by a green arrow), and sends it a sequence of events:
the
engine_ui:setup
event, fielded by the engine-ui ruleset which creates a new channel suitable for use by the UI, and returns that channel’s ID which is bound to the namenewUiECI
the
wrangler:pico_created
event, fielded by a wrangler rule, which saves the name, and installs the subscription ruleset (shown by a green arrow)the
engine_ui:box
event, fielded by the engine-ui ruleset which stores away the name and background color so that the new pico can be correctly rendered in the developer UI
Finally that rule raises a wrangler:new_child_created
event for the parent pico. And, the child pico, after it has finished with its work, sends a wrangler:child_initialized
event back to the parent pico.
...
Events to which wrangler reacts
event | raised by | attributes |
---|---|---|
| UI or KRL application | required |
| Wrangler (not for use by KRL programmers) to the new child pico |
|
| UI or KRL application | required |
| KRL application | none (implicit) |
Events which wrangler raises
event | to/from | attributes |
---|---|---|
| internal to parent pico | passed through from initial and the |
| internal to child pico | |
| from child pico to parent pico | |
| internal to parent pico | passed through from initial |
The KRL programmer may choose to write rules that react to these raised events.
...
A pico can have as many inbound channels as it needs. See Managing Channels for more information. A pico can only create and delete channels for itself.
...
For example, this KRL code creates a channel when the app_section_collection
ruleset is installed into a pico (see the Pico to Pico Subscriptions Lesson for context):
Code Block |
---|
ruleset app_section_collection { ... global { ... tags = ["app_section_collection"] eventPolicy = { "allow": [ { "domain": "section", "name": "*" }, ], "deny": [] } queryPolicy = { "allow": [ { "rid": meta:rid, "name": "*" } ], "deny": [] } } rule initialize_section_collection_pico { select when wrangler ruleset_installed where event:attr("rids") >< meta:rid if ent:section_collection_pico_eci.isnull() then wrangler:createChannel(tags,eventPolicy,queryPolicy) setting(channel) fired { ent:section_collection_pico_eci := channel{"id"} ent:sections := {} } } ... } |
...
Note in line 5, the use of the array operator head()
to convert the array of channels returned by the wrangler:channels()
function into a single channel map.
...
Wrangler reacts to the wrangler:install_ruleset_request
to install a specified ruleset into the pico. It takes two forms:
When given one attribute,
url
, it installs the KRL code at that URL into the pico.When given attributes
absoluteURL
andrid
, it resolves a URL substituting the givenrid
as a KRL filename based on theabsoluteURL
. It installs the KRL code at that URL into the pico.
The second form is useful when the KRL programmer has several rulesets which operate together in a pico-based system. It allows the bootstrapping of the system by installing a single ruleset which then installs all of the others using simple RIDs instead of absolute URLs.
Both forms take a config
attribute that contains a map of the configuration parameters for the ruleset.
In either form, wrangler raises the wrangler:ruleset_installed
event, passing rids
, an array of RIDs containing the RID of the ruleset just installed.
...
For example, wrangler:rulesetMeta(“hello_world”)
(which refers to the ruleset shown in the Pico Engine Quickstart page), would return this map:
...
It raises the wrangler:ruleset_uninstalled
event, passing through all attributes of the original uninstall event. The KRL programmer can write a rule which selects on that event, as needed.
...
picoQuery
Wrangler provides
and shares
a function named skyQuery
picoQuery
which is a user friendly way to make an HTTP a request between picos. It . picoQuery
uses ctx:query()
if the pico is on the same host and HTTP if it is not. When using HTTP, it provides cleanup and returns the error if the returned HTTP status was not 200.It is mainly used to programmatically call functions inside
Info |
---|
The |
picoQuery()
is mainly used to programmatically call functions inside of other picos from inside a rule. However, deadlocks are possible due to its synchronous nature (e.g. do not let two picos query each other simultaneously). See Accessing a Function Shared by Another Pico for more information.
Parameters
Optional parameters are italicized.
Parameter | Datatype | Description |
---|---|---|
| String | The ECI to send the query to |
| String | The RID of the ruleset to send the query to |
| String | The name of the function to query |
params | Map | The parameters to be passed to the function on the target pico. Given as a map with parameter name as the key and argument as the value. |
_host | String | The host of the pico engine being queried. |
_path | String | The sub path of the url which does not include mod or func. |
_root_url | String | The entire URL except eci, mod , func. |
meta:host (the pico engine itself). |
If _host
is missing or the same as the result returned by meta:host
, picoQuery()
will use ctx:query()
instead of HTTP.
Returns
Success: the result of the function queried for.
Failure: a map of error information which contains the error
and other optional information:
|
|
|
|
Info |
---|
This map represents a breaking change. The previous map returned |
Example
|
|