Skip to content
SOFe edited this page Aug 12, 2018 · 25 revisions

A UiNode is a step in the libkinetic flow. The lifecycle of a UiNode is like this:

  • Start: The node's onStart handlers are called.
    • They may bring the node to the completion state directly.
    • They may bring the node to the post-completion state directly, determining the next node to execute.
    • They may create variables at the node scope.
  • Execution: The node executes normally.
  • Completion: The node's onComplete handlers are called.
    • They may determine the next node to execute. The next node can be another node in the current subflow, or a

There are many types of UiNode:

  • Flow control nodes
    • <exit>: the flow should be terminated after this node
    • <buffer>: the execution part does nothing at all. Useful for inserting some onStart/onComplete handlers here.
    • <call>: calls a wizard.
    • <series>: Execute children one by one
    • <mux>: Selects one child based on a controller
    • <index>: Equivalent to a <list> with a <mux>
  • Standard user interface:
    • <form>: literal CustomForm
    • <list>: dynamic MenuForm
    • <info>: ModalForm, can be combined with <mux> to handle yes/no buttons
  • Advanced user interface:
    • <recurForm>: a CustomForm with recurring elements. Literal elements per iteration. Number of iterations determined by a provider.
    • <dynForm>: a complex wizard with a MenuForm whose elements can be added or edited with another CustomForm or deleted.

See List of UiNode types for detailed description.

Node state (onStart/onComplete) handler

The onStart/onComplete handlers of a UiNode are elements in the <onStart>/<onComplete> element of a UiNode.

onStart/onComplete handlers can modify the node state and restart/skip it. The following behaviour are available:

  • start: starts from the first onStart handler again.
  • nil: nothing special, approaches to the next onStart/onComplete handler.
  • execute:
    • For onStart: skips any remaining onStart handlers and starts execution directly.
    • For onComplete: restarts execution.
  • complete:
    • For onStart: skips the remaining onStart handlers and execution, jumps to the first onComplete handler.
    • For onComplete: restarts from the first onComplete handler.
  • skip: Skips the whole node (skips execution, skips all remaining onStart/onComplete handlers), approaches to the next node in the flow. The next node target can also be provided, which must be a sibling of the current UiNode or an of its executing parents.
  • break: Breaks a subflow, skipping any execution and remaining onStart/onComplete handlers. A target can be provided to specify the flow level to break. By default, it breaks the current UiNode's parent flow.
  • exit: Breaks all subflows. If the target variable is set, it will be used as a UserString to be sent to the user.

Common node state handlers

The following nodes are available in both onStart and onComplete:

<controller>

Executes an UiNodeStateHandler controller class in the class attribute.

onComplete-only handlers

In addition, the following nodes are allowed in onComplete only:

<always>

<always action="xxx"/> is equivalent to <const value="true" ifTrue="xxx"/> (<const> is a conditional handler).

<goto>

<goto target="xx.yy"/> is equivalent to <const value="true" ifTrue="skip" ifTrueTarget="xx.yy"/> (<const> is a conditional handler).

Conditional handlers

Conditional handlers are nodes that can emit either true or false. They may have onTrue/onFalse attributes determining the behaviour of the currently executing node, and onTrueTarget/onFalseTarget attributes indicating their skip/break behaviour if needed.

There may be multiple trees of conditional handlers under the same <onStart>/<onComplete>, and they will be executed top-down.

Multiple conditional handlers may be joined and added to the same UiNode by <or>, <xor> or <and>. In addition, each conditional handler may have a not attribute that inverts its own output (but not the output of its children; this is different for <or> and <and> according to de Morgan's theorem).

Conditions are evaluated top-down and follow short-circuit rules. That is, if a condition under an <or> returns a true value, or if a condition under an <and> returns a false value, the next conditions will not be evaluated. Short-circuiting may be disabled by setting the shortCircuit="false" attribute on the <or>/<and>. There is no short-circuit for <xor>.

Types of conditions (in addition to the group permissions <or>, <xor> and <and>) include:

<hasVar>

Checks if a flow variable exists and is not null.

An attribute name specifies the name of the variable to check.

<predicate>

Triggers a UserPredicate controller specified in the controller attribute.

<permission>

Checks if the user has the permission in the name attribute.

<const>

Returns the constant boolean value in the value attribute.

Clone this wiki locally