...
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.
...
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.
...
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. |
If _host
is missing or the same as the result returned by meta:host
, picoQuery()
will use ctx:query()
instead of HTTP.
...
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
|