LSPS documentation logo
LSPS Documentation
Event Processing

When the user or the system performs an action on a form component, the form component produces an event of a particular type. If the form component has a listener for the type of the event, the event is usually immediately processed in the event-processing cycle, the exception being the non-immediate ValueChangeEvents).

The event-processing cycle, or request-response cycle, processes the event in a set of steps that gradually perform actions defined on the listeners of the events.

simpleRequestResponseFormProcessing.png
Form event firing

You can find a detailed schema of the cycle here.

The event-processing cycle performs the following:

  • Updates of internal values (References to internal values are defined as bindings on form component.)
  • Validates values
  • Executes listener logic as defined by their handle expression
  • Fires application events
  • Merges or clears any View Models data
  • Evaluates the Navigation expression

If a listener requests the submit action, the form is submitted and the event processing cycle finishes. If submit was not requested and a processed listener fired an application event, the event-processing cycle is repeated and the newly fired application events are processed. Otherwise, the components are refreshed and any produced ApplicationEvents are processed. If no such events exist, the event processing cycle finishes.

simpleRequestResponseProcessedEvents.png
Event processing cycle
When the event processing finishes, the cycle executes the listener actions if requested, that is, the save, submit, and navigate actions:

  • Submit: defines if the document or to-do is submitted as part of the event handling;
  • Persist: if enabled, the relevant data in the processed components is persisted as part of the event handling; unlike on submit action, if the form is used by a to-do, the to-do does not become finished; if part of a document, the document remains open; persist is performed after the merge to the screen level before the transaction is committed.
  • Save action: defines if the to-do or document is saved;
  • Navigation: defines the location where to navigate after the event is processed; you can navigate to a to-do or document, URL, custom application page (refer to the descriptions of the data types defined in the human.navigation.datatypes resource in the Standard Library)

The event processing and the listener actions are executed within a single database transaction so that if the processing fails at any stage, the database is rolled back to a consistent state.

simpleRequestResponseProcessedComponents.png
Database transaction on event processing and listener actions
Events Listeners