The RASTCLSP_t1 describes a design pattern for creating user interfaces (UI-s) that consist of UI elements called widgets. In the context of this specification a widget is a container that has some type/class specific behavior and it as a container is allowed to contain only other widgets as its elements. The widgets do not have to have a graphical representation. For example, a menu widget can be implemented as a sound menu.
All widget instances have a state machine that has at least one state, "zero". At instantiation the widgets are at the state "zero". Whenever a widget enters the state "zero", all of its sub-widgets, the widgets that it contains, are recursively moved to their state "zero".
States can be divided into sets, where the states are the elements of the sets. In the context of this specification the sets are called state clusters. All of the sets include the state "zero". An intersection of any 2 sets, state clusters, always contains only one element, one state, the state "zero". With the exception of the state "zero", which belongs to all possible state clusters all times, all states belong to the "default state cluster", unless they have been explicitly declared to belong to some other, user defined, state cluster.
All states and all state clusters have an entry function and an exit function. Each pair of states and each pair of state clusters has two transition functions, one transition function for each direction. By default the functions are empty functions, id est in the context of this specification it is acceptable for those functions to do nothing. If states were nodes of a graph and the edges of that graph were non-directed edges, where each non-directed edge designates 6 functions, exit-transition-entry in both directions, then all states that belong to a single cluster form a complete graph. The same with state clusters. If state clusters were nodes of a graph and the edges of that graph were non-directed edges, where each non-directed edge designates 6 functions, exit-transition-entry in both directions, then all state clusters form a complete graph.
At every state change, where the origin and destination states reside at different clusters, the functions are executed in the following order:
If the states reside in a single cluster, including the case, where the origin and destination states match, then none of the cluster entry, exit, transition functions are executed and the state associated functions are executed in the following order:
The state cluster exit function and the state cluster entry function of the "default state cluster" are always empty functions. All cluster transition functions between the "default state cluster" and any other state cluster are always empty functions.
In addition to the previously described state machine each widget includes 2 additional state bit pairs: a visibility state bit pair and an onoff state bit pair. Each of the bit pairs contains a relative value bit and an absolute value bit. All widgets are containers that can contain other widgets as container elements, which in turn can contain other widgets, which in turn can contain other widgets, which in turn can contain other widgets, etc. If no bit-value-change-process is in progress, then the boolean formulae in the following code segment hold:
ob_widget_container.insert(ob_widget_container_element) // all widgets are containers // The "∧" designates conjunction. ob_widget_container_element.visibility.absolute_value_bit ≡ ≡ (ob_widget_container.visibility.absolute_value_bit ∧ ob_widget_container_element.visibility.relative_value_bit ) ob_widget_container_element.onoff.absolute_value_bit ≡ ≡ (ob_widget_container.onoff.absolute_value_bit ∧ ob_widget_container_element.onoff.relative_value_bit )
The onoff state bits can be useful for controlling
network traffic consumption and
the consumption of computational power.
The onoff state bits can be also useful in a situation,
where the parent widget switches
some of its subwidgets on only after
a creation of an authenticated session.
The visibility state bits allow widgets to be
erased from screen and redrawn to screen without changing
their visual properties, which can include user input that was
present at those widgets before they were erased from screen.
As the value of the the absolute value bits of a widget instance depends on the absolute value bits of all of the widget instances that are its containers, the RASTCLSP_t1 widget API does not allow the absolute value bits to be manipulated directly. Each widget has public methods set_relative_value_true_2_false() and set_relative_value_false_2_true()
Those functions are expected to be
implemented at widgets' base class at
the RASTCLSP_t1 implementation, but they
contain widget developer overridable hooks,
which are not optional, but are required to be
overridden by the widget developers.
The RASTCLSP_t1 implementation of the
hooks, which are all required to be overridden, must
throw an exception telling that the methods
are expected to be overridden. The widget developer
is allowed to use an empty function as an overriding
Instantiation of a widget class always creates widgets, where
ob_widget.visibility.relative_value_bit ≡ false ob_widget.onoff.relative_value_bit ≡ false
All widgets are required to work in their normal mode of operation while
ob_widget.visibility.absolute_value_bit ≡ false ob_widget.onoff.absolute_value_bit ≡ true
The rest of the details are too exhaustive to be described at this specification, but the absolute_value_bit switch has multiple stages, which are depicted at the following drawing: