Projects:Widget Loading Improvements/Specs

Functional Requirements

There is not any specific functional requirement, the main goal is to reduce the time spent to load the widgets in the user's Workspace.

Technical Specs

Before this project, there are two requests being fired right after the user has logged-in into the application which are intended to render in the Workspace the set of widgets available for that user. Both requests are calling the action handler called MyOpenbravoActionHandler with different objectives:

• A request to reload the widgets: RELOAD_WIDGETS
• A request to put the the widgets in the correct place: WIDGET_MOVED

A First Approach: Merging Requests in Session Dynamic

During this project, as a first approach, the request to MyOpenbravoActionHandler was replaced by getting the information about the widgets as part of the SessionDynamic request.

This solution was discarded because the SessionDynamic request was not fast enough (the results of the measurements can be seen here) and because of the fact that this information is not required to complete the log-in (the user can start working without having the Workspaced completely loaded).

For this reason, the final solution taken was to leave the request to MyOpenbravoActionHandler independent from the SessionDynamic, and try to make the first load of the widgets as fast as possible.

RELOAD_WIDGETS Request

Currently this is the most time consuming request being fired once the user has logged-in into the application.

It is in charge of retrieve the widget instances that should be rendered into the Workspace of the user in the current context. The set of widgets that the user can add into the Workspace are retrieved also.

There are some improvements that can be applied into the 'MyOpenbravoActionHandler in order to reduce the time spent to retrieve all this information:

• Keep widget class definition in cache: the definition of the widget classes depends just in the information stored in the Application Dictionary. So this information can be kept in cache instead of doing a database query on every request. Therefore, we will keep this information into a data structure in cache when there are not modules in in development status.

• Use one query to retrieve the widget instances at organization level: when retrieving the widget instances available at organization level, a query is executed for each organization. This is slow if the amount of organizations is high. For this reason, we will use just one query to retrieve all the widget instances at organization level.

• General improvements: some queries can be improved in order to retrieve just the strictly required information, and there are some parts where it is possible to instantiate proxies instead of the whole DAL object.

WIDGET_MOVED Request

This request is performed once the RELOAD_WIDGETS request is completed. It is in charge of place the widgets at their proper position in the Workspace. It detects changes in the widget instances between the information in the client and the information retrieved at the backend.

This request is not necessary when the user logs-in, because of the fact that it will not detect any difference between the information in the client (recently obtained with the previous RELOAD_WIDGETS request) and the information retrieved with this request itself.

For this reason, this request can be directly skipped after the log-in. But after subsequent RELOAD_WIDGETS requests the behavior will remain unchanged and the WIDGET_MOVED request will continue being performed.