View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

ERP/2.60/Projects/UI Technology/View Definition

Contents

Prototype User Interface Model

The goal of the prototype is to deliver a system which makes it possible to define selectors and selector details and behavior. This means that it should be possible to define which columns are shown in the selector suggestion box and which columns are visible in the popup grid and how they behave. To support this we need a user interface model which allows a user/consultant to specify these details. As we need this user interface model anyway the idea is to try to generalize it to support also other types of views, for example an editable grid.

Design Aspects

This document tries to define a model which allows defining grids and forms while still trying to maintain both efficiency and flexibility. The following aspects need to be taken into account:

Main Structure: view, fieldgroup, field

To clarify the concept of a view. A view is a user interface component which from the user can be seen on its own, separate from other parts of the UI. All parts of one view play together or are strongly related. A view can for example also be seen as a transactional unit, all actions in one view are committed as one transaction to the database. A view can be a single form, a master detail or a form which tabs with grids and form fields. A view is typically shown in the main tab of a multi-document interface.

A view has zero or more field groups. A field group can be used to create (hierarchical) groups of fields. It's main purpose is to support layout and grouping of fields in the user interface. Field groups can be implemented in different ways (as supported by the template), for example a field group can be rendered as tabs within a form, or as sections within one tab or combinations. A field group always belongs to exactly one view. A view does not need field groups, so also without field groups (and just with fields) it should be possible to render a workable user interface.

A view also has zero or more fields. A field is either directly linked to a column from the database or is a so-called computed field. In the last case it must have a reference to determine its type.

A view has a view type (discussed below). The view type determines how the view definition is rendered (as a selector, an editable grid or as something else).

A view has a data source and a view handler. The data source and view handler are java classes which implement different part of the behavior of the view. The view handler takes care of executing the actions which are directly originating from the view (save, update, button actions).

A view also has a filter or where clause to limit the data shown in the view. The filter is a hql where clause.

Modules can provide new views and can add fields and fieldgroups to existing views.

View Type and View Features

A view type defines how a view should be rendered/generated. A view type defines two main things:

The concept of features is an important concept in the user interface model. It tries to support flexibility in extending/adding views and templating while still offering a form of formalized control.

A view, field group or field can have zero or more features linked to them. A feature determines/directs the template to generate or render the view/fieldgroup/field in a certain way. There are three types of features:

A feature can be applicable to field, fieldgroup or view level. When defining a view and selecting a viewtype the user can then set the values of the view features for the view, field(s) and fieldgroup(s). The applicable features are the one defined for the view type.

The feature values of the view/field/fieldgroup are passed to the template as part of the entities (view/field/fieldgroup) themselves.

Let's take an example. In the current Openbravo window/tab/field definition it is possible to define if a field is visible in the grid or only in the form. To implement this same visualization the following has to be done:

Another example, when defining a grid it should be possible to define which columns are sortable and filterable. To support defining these type of grids a new view type is created: 'standard grid'. This view type defines two tag features: sortable and filterable. Then when a user creates a new view with this view type he/she can select for each field if it should be sortable and or filterable by selecting the correct tag features.

The proposed feature system above is quite simple and can be made more advanced by supporting a complete type system. At the moment the assumption is that the three types (boolean, string, enum) are enough.

Template

Templates are explicitly modeled in the system. A template is always used to generate a complete view. A template has a link to a template file (freemarker, xtext) which contains the template code. The template code may use other sub templates or functions defined in other utility templates.

Datasource

A view needs a data source to provide it with data. A view can make use of a standard data source created for each Openbravo entity or can make use of a java class which implements the data source interface. The data source table has a name, description, an entity and a java class field. If the entity is selected then the data source is automatically created on the basis of the entity. In case the java class is set then it is a computed data source which much implement the OB data source interface.

A data source belongs to a module, a module can provide new data source implementations.

ViewHandler

The view handler takes care of executing specific user interface actions related to buttons or other user interactions. For some views (only doing display for example) a data handler is not directly necessary as all the data related actions are done by the data source.

A view handler belongs to a module, a module can provide new view handler implementations.

Selectors and View Definition

To integrate selectors and view definitions the proposal is to define a new reference type: ad_reference_selector which has a reference to a view record. The view can then for example have the view type 'selector'. This view type can for example have a feature to determine if a field is present in the suggestion box and/or in the popup div.

Note that if/how modules can add new reference types is not clarified.

Model Definition

View

A view has the following fields:

A view has the following multi-occurence data:

Field group

A field group can be used to create (hierarchical) groups of fields. It's main purpose is to support layouting and grouping of fields in the user interface. Field groups can be implemented in different ways (as supported by the template), for example a field group can be rendered as tabs within a form, or as sections within one tab or combinations. A field group always belongs to exactly one view. A field group has the following fields:

Field

A field defines the visualization of a single property of an entity or a computed property. A field belongs to one view always. A field has the following properties:

View Type

A view type has the following fields:

A view type has zero or more features.

View Feature

A view feature has the following fields:

View Feature Enum Value

A view feature of type enum has one or more enum values. These are defined in the View Feature Enum Value. The enum value has the following fields:

Feature Value

Models the value of a feature for a certain view, fieldgroup or field. It has the following fields:

Note, only one of View, FieldGroup and Field should be set.

Template

A template has the following fields:

Datasource

A data source has the following fields:

View Handler

A view handler has the following fields:

Alternative models

An obvious alternative model would be to explicitly model forms and grids and other view types in tables. The advantages of this type of approach is that the functionality is more explicitly defined, i.e. less abstract. However there are also some disadvantages of a more explicit approach or in other words advantages of the proposed approach above:

Future extensions/Discussion items

Retrieved from "http://wiki.openbravo.com/wiki/ERP/2.60/Projects/UI_Technology/View_Definition"

This page has been accessed 469 times. This page was last modified on 2 November 2009, at 12:59. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.