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

Projects:UI Technology/StoringViewState

Contents

Introduction

This page discusses the planned view state saving capabilities of the new Openbravo user interface.

Storing view state makes it possible for a user to configure the user interface to his/her wishes and store this configuration using a name. The user can for example set which columns are visible, the column width etc. When the user then logs in later he/she can again select the stored view state and restore the previously saved configuration.

View state can be stored on different levels: system, client, organization, role, user. A view state is always stored for a window and contains the state of all tabs inside that window.

View state can also be stored in a module, so that a module can deliver view states with other functionality. The module of a view state can be set in the view state maintenance windows available to consultants.

The view functionality should be added to the org.openbravo.client.application module.

Saving views: flow

The user changes the configuration of the grids: column width, visibility etc. Then he/she wants to save the current view. For this in the toolbar there is a specific button, he/she clicks it and selects the 'Save View' option:


Ob saving view 1.png


Then a name needs to be entered and the view can be flagged as the default view (which is used when the window is opened from the menu or quick launch).


Ob saving view 2.png


Next to creating and naming a view the following can be done:

View State Definition

The information stored for a view (i.e. the view state) consists of the following information:

The view state does not hold information about the selected records or which record is shown in a form.

Note that Smartclient offers a standard api in the ListGrid class to retrieve and set the state of a list grid. This state the column, sorting and filtering information. The smartclient view state also includes which objects have been selected, this last part should be ignored when saving the state. The smartclient form does not have a state retrieve/set api, but this is less important as only very little state information is stored for a form.

Delete or rename/edit a view

The user should be able to delete or rename/edit a view. The following aspects need to be taken into account:


Ob saving view remove.png


View flagged as default

As views can be defined on different levels of granularity, it is possible that there are multiple default views in the system. The one on the most detailed level should be chosen as the default.

On one level only one default can be present. So when setting a view as the default to start with then other views on the same level should be set to non-default.

Data Model

Views are stored in a separate table which is very similar to the ad_preference table. This table will have the following columns:


Note: the table should be added to the ad dataset so that entries with a module are exported with a module.

Storing views on system/client/org/role level

The system will support storing views on different levels: system, client, organization, role and user. When a user visits a window the views are collected from all the available levels for the current role, org and client of the user.

All the collected views are displayed in the drop down available under the view button.

Special application administrator users can create and store views on one of the above levels.


Table with the values of the columns that define each level:
Level AD_Client_ID AD_Org_ID Visibleat_Role_ID Visibleat_User_ID
System System * null null
Client Yes * null null
Organization Yes Yes null null
Role Yes * Yes null
User Yes * null Yes

Flagging a user as view administrator

A user can administrate any level depending on the role and organization he has logged at. The level is defined as follows:

Selecting system/client/role level to store views

When a level administrator creates/stores a view he/she will be presented with an extended dialog which next to the name and default field also shows fields to save the view on a different level than user (system checkbox, client combo, org combo and role combo).

The flow to determine on which level a view is stored is similar to the one supported in MyOB. Some code can be copied/made generic from the MyOpenbravoComponent java class.

When an admin user creates a new view. He/she can select on which level to store the view state.

This dialog is shown in the popup where the user can set the name of a view.

Editing/deleting views taking into account different levels

A normal (non-application admin) user can only delete/edit views defined on user level. The views on other levels will not have an edit/delete option and can't be changed.

If a user is an administrator of a level then an edit/delete option will be visible for each view in the flyout defined on the level he/she is admin. The application administrator can also change the level of an existing view.

Additional Aspects - Open Topics

The view state can be stored on module level, modules can provide default view states. To store the state on view level, the consultant has to visit the view maintenance page and set the module explicitly by hand.

The system should visually change the view icon in the toolbar if the user makes changes to the user interface which can be saved as a view.--> or does this happen too quickly, a user who collaps/expands a form section will get this icon being highlighted?

Should view names be translatable --> not at the moment

There should be one additional view called default: this is the view which does not contain special settings, and can be selected explicitly by the user.

Retrieved from "http://wiki.openbravo.com/wiki/Projects:UI_Technology/StoringViewState"

This page has been accessed 4,961 times. This page was last modified on 8 June 2012, at 05:31. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.