View source | View content page | Page history | Printable version   

Projects:Client Side Event Handlers Extension/Specs


Functional Requirements

The objective of this project is to provide the infrastructure needed to execute actions before and/or after an event fired from a standard window of the User Interface.

The provided infrastructure should be flexible enough to accept different events fired from any standard window like saving, updating or deleting a record but also when printing or opening a new record.

In particular, this project will provide the ability of launching actions related to the save event:

In these actions, it will be possible to identify if the record is being saved or updated.

With this implementation it will be possible to implement some features not available until now, like for example:

Known Limitations

If the grid is refreshed as part of a post-save action, and the save has been launched by selecting a record in other page of the grid, the selection will be lost after refreshing the grid.

Technical Specs

Function Registry

The central part of the implementation of this project is the creation of a new registry. This registry will allow to keep the different actions to be executed, organized by each supported event. Initially just the Pre-Save and Post-Save events are going to be supported.

Currently there exists a similar registry used by the client side callouts. As this registry implementation has similarities with the event handler registry to be implemented, a registry super-class will be implemented. Both registries will inherit from it and implement their particularities. This will also allow to have a base implementation for future registries.


As per the image above, the existing onchange function registry stores functions by tab and field. In the case of the event handler registry it will store the actions to be executed by tab and event type (pre-save, post-save...).

In the same way as it is done for onchange functions, it will be possible to launch multiple actions for the same tab and event type, being possible to assign a priority for each one.

Save And Update Events

As mentioned before, the events that will be controlled are the save and updated events. This implies that the event handler registry information should be consulted before and after save (update) a record.

There are several flows through the UI which allows to save or update a record. All of them must be handled in order to execute the corresponding actions:

In the case of auto-saving it must also be taken into account the auto-save action, i.e., the action that caused the firing of the auto-save. The execution flow must be the following:

  1. Save the current record (auto-save)
  2. Execute the post-save actions
  3. Execute the auto-save action

For example, if the auto-save is fired because we have clicked into another record, then the execution flow will be:

  1. Save the current record (auto-save)
  2. Execute the post-save actions
  3. Select the new record

Asynchronous Execution of Actions

Once it is detected that a supported event must launch actions in a tab (using the registry), the execution of all the actions will start. This execution will be asynchronous, i.e., one action will not be fired until the previous one has finished.

To ensure a correct behavior, each action will be responsible to call to the next one when it finishes.

The actions are stored by priority number within the registry, this way the actions will be executed orderly.

This mechanism for asynchronous execution will be analogous to this one, used to implement hooks within WebPOS.

Retrieved from ""

This page has been accessed 1,725 times. This page was last modified on 19 July 2016, at 10:40. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.