Projects:Client Side Event Handlers Extension/Specs

Contents 1 Functional Requirements 1.1 Known Limitations 2 Technical Specs 2.1 Function Registry 2.2 Save And Update Events 2.3 Asynchronous Execution of Actions

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:

• Pre-Save actions: these actions will be fired before saving or updating a record.

• Post-Save actions: these actions will be fired right after saving or updating a record.

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:

• Perform client-side validations before saving a record.
• Perform server-side validations before saving a record.
• Show different kind of messages after saving a record.
• Refresh the grid after saving a record.
• Open a new window after saving a record.
• Etc.

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:

• Save (update) a record (in grid or form view) using the toolbar button.
• Save (update) a record (in grid or form view) using the Ctrl+S shortcut.
• Save (update) a record in grid using the save button of the record.
• Auto-save after leaving a record (in grid or form view).
• Auto-save after leaving a record in grid view with the keyboard (UP KEY, DOWN KEY, ENTER KEY, TAB KEY).
• If auto-save confirmation is enabled, save (update) a record if the confirmation is accepted.

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.