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:
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).
Next to creating and naming a view the following can be done:
- update view (should be shown next to save and delete in the pulldown), updates the current view.
- a view can also be deleted or renamed.
View State Definition
The information stored for a view (i.e. the view state) consists of the following information:
- Grid
- column order, width and visibility in a grid
- filter and sort state in a grid
- Form
- section field collapse/expand state in a form
- Layout:
- drag position of child tabsets in their parent
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:
- the delete option is available in the drop-down, when clicking it a popup appears which make it possible to select a view and remove it.
- the rename option can be visualized in the flyout by adding a pencil icon next to the view name. When clicked a small dialog popups which allows to set the name and also set the default option.
- a view can only be deleted if:
- the view is stored on user level
- if the view is a system/client/role view then user must be an administrator and has the right to create views on system/client/role level.
- a view can only be renamed if:
- the view is stored on user level
- if the view is a system/client/role view then user must be an administrator and has the right to create views on system/client/role level.
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:
- XX_view_state_id: primary key (prefix depends on the module)
- ad_module_id: the module_id, can be null
- ad_client_id: defines the client for which the view state applies
- ad_org_id: defines the role for which the view state applies
- active, updatedby, updated, createdby, created
- name: the view name (does not need to be unique)
- content: the view state, the view state can be a fairly large object, so a large column size (>10000) should be chosen (or text blob)
- visibleat_client_id:defines the client for which the view state applies
- visibleat_org_id:defines the org for which the view state applies
- visibleat_role_id:defines the role for which the view state applies
- visibleat_user_id:defines the user for which the view state applies
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.
| 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:
- System: the system administrator can store views on system level (visible to everyone).
- In ad_role there is a new flag: client admin. If this flag is checked then the user can store views on client level. The exact client to store the view must be selected when creating a view.
- In ad_role_orgaccess there is a flag: is_org_admin. If this flag is checked then the user can store views in all orgs for his/her current role with this flag checked.
- In ad_user_roles there is a flag: is_role_admin. If this flag is checked then the user can store views for that role.
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.
- First the user has to select the level on which he/she wants to store the view: System, role, org or client. Only the levels on which the user has admin rights should be shown.
- Then for the chosen level, he/she should select the specific client, org or role on which the view should be stored.
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.