Invalidate context
Actions – Abstract
The action Invalidate context causes the current data context for the execution of an input form to be declared as ‘invalid’ and therefore re-evaluated. The unsaved processing state of the ‘form data’ from the current input form, including the reference to an object – regardless if existing or yet to be created – remains unchanged.
The action Invalidate context causes the current data context for the execution of an input form to be declared as ‘invalid’ and therefore re-evaluated. The unsaved processing state of the ‘form data’ from the current input form, including the reference to an object – regardless if existing or yet to be created – remains unchanged.
However, the selection of the input form to be associated is re-evaluated against the background of the data changed since the current form was opened:
If the re-evaluation of the relevant Association criteria according to the best-matching principle shows that a different input form ‘fits better’, it is loaded with the available data and presented instead of the previously used form.
If the current input form proves to be still relevant, it remains open. The trigger Form data loaded is then not activated, whereas the trigger ‘Context changed’ becomes active.
Overall, this action is typically used to specifically question the input form’s current assignment in response to a certain trigger, possibly combined with a test result of a behaviour type indicating potentially critical changes, if the change to a ‘more suitable’ form should be carried out immediately as opposed to automatically once the changes are saved.
►NOTE◄ Linking a target element has no effect on the action, since the context can only be invalidated overall. Therefore, the action can also be implemented in an embedded form (see Embed forms (Sub-forms)) to invalidate the context of the main form at runtime.
Use case example
A default input form for Shipments offers two alternatives for the Shipment type via the Combobox: ‘Shipment’ (default) and ‘ULTRA-EXPRESS’
As soon as the Shipment type ‘ULTRA-EXPRESS’ is selected, the entry of the shipment details should be continued immediately in a specific entry form for this shipment type. For these, an assignment criterion has been assigned which, in addition to the general Check type for ‘Shipment’, also includes the Shipment type (for ‘ULTRA-EXPRESS’) and exceeds all association criteria for the default shipment form in terms of priority.
Configuration:
|
|
As the selection change for the shipment type is performed by a Combobox, a ‘change’ behaviour is implemented for this form element and configured as shown on the left:
|
►NOTE◄ In the minimal constellation described here, with only two shipment types and corresponding forms, the procedure seems rather cumbersome at first glance. In practice, however, additional shipment types, secondary conditions and correspondingly more forms and more complex assignment criteria will quickly come into play. Invalidate context may have to be implemented for other critical form elements in the same way as in this example. The selection of the ‘suitable’ input form for each context, on the other hand, depends only on the interaction of the characteristics of the data with the association criteria for the forms. The overall concept can also be used to divide the data acquisition workflow into a sequence of forms, which are ‘run through’ by the same object depending on the progress of the acquisition. For the users, this creates the impression of an ‘assistant’, guiding them through the process of data acquisition without imposing a completely rigid methodology.