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:
- it should be possible to support both forms and grids in one model
- the current functionality, to have one set of fields used for both single as multiple record/object display should be supported (is efficient)
- the model should offer functionality to define a view with fields and fieldsgroups.
- the view is part of a ui generation framework, based on the view definition the resulting ui is generated (using templates).
- it should be possible to link a view to a specific rendering/generating-method
- the model should allow easy extendability with modules offering new view types.
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:
- it has a link to a template
- it defines features which are relevant for the template and can be used to control/direct the template
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:
- boolean features: these are features which are used to tag the field/fieldgroup/view so that the template will treat the view part in a specific way.
- value features: these are features for which a value has to be entered when linking it to a field/fieldgroup/view, this value can then be used inside the template.
- enum features: these are features which can only have one of a distinct set of values. The possible values are defined with the field.
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:
- A template needs to be created which is capable of generating a form/grid view based on a view definition with fields.
- A viewtype with the name 'grid-form' view type is defined. This view type should have two boolean features (on field level): grid and form.
- Then a view is created with the view type equal to the 'grid-form' view type.
- When selecting/setting the fields of this view the consultant can set the grid and/or the form feature as they are features defined by the selected view type.
- When the template generates the user interface the features selected for a field define if the field is present on the form, the grid or both.
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:
- id: primary key
- Module: the module to which the view belongs.
- Name: unique name within the module
- Description: free format description
- Title: the page/grid title
- Help/Comment: the help text or comment displayed in the popup grid
- Tracing/active fields: updated, createdBy etc.
- View Type: link to the view type
- Data source: link to the data source
- ViewHandler: a class which handles the json data requests for both the suggestion grid and box, if not set then the default json data handler is used.
- ViewFilter: a hql where clause used to filter the data shown in the view
A view has the following multi-occurence data:
- zero or more field groups
- zero or more fields
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:
- id: primary key
- Module: the module to which the field group belongs
- Name: unique name within the module
- Description: free format description
- Title: the page/grid title
- seqno: sequence within the view or parent field group
- Help/Comment: the help text or comment displayed in the popup grid
- View: the view to which the field group belongs
- Parent field group: is a field group belonging to the same view but not equal to the field group itself
- Tracing/active fields: updated, createdBy etc.
- A set of zero or more features as defined by the view type of the view to which the field group belongs.
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:
- id: primary key
- Module: the module of the field
- Name: unique name within the view
- Code: a unique name which is used in the code (javascript etc.), if ad_column is set then this can be derived from the property name
- Description: free format description
- Title: the page/grid title
- Help/Comment: the help text or comment displayed in the popup grid
- View: the view to which a field belongs
- Tracing/active fields: updated, createdBy etc.
- FieldGroup: a field belongs to at most one field group, the field group must exist in the same view
- seqno: sequence within the view or parent field group
- display fields (displaylength, formatting & validation), see discussion items below
- ad_column: if the datasource selected in the view is for an entity then only the columns/property of that entity may be selected
- ad_reference: if ad_column is not set then the field must have a link to the reference to set its type
View Type
A view type has the following fields:
- id: primary key
- Module: the module providing the view type
- Name: unique name
- Description: free format description
- Title: the page/grid title
- Help/Comment: the help text or comment displayed in the popup grid
- Tracing/active fields: updated, createdBy etc.
- Template: the template to use to render the views which selected this view type.
A view type has zero or more features.
View Feature
A view feature has the following fields:
- id: primary key
- Name: unique name
- Code: a unique and stable code which can be used inside a template
- Description: free format description
- Title: the page/grid title
- Help/Comment: the help text or comment displayed in the popup grid
- Tracing/active fields: updated, createdBy etc.
- Type: boolean, value or enum
- Level: view, fieldgroup or field
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:
- id: primary key
- Name: unique name within the View Feature
- Value: a unique and stable code which is the value of the enum passed to the template
- Tracing/active fields: updated, createdBy etc.
Feature Value
Models the value of a feature for a certain view, fieldgroup or field. It has the following fields:
- id: primary key
- View Feature: link to the feature itself
- Value: the value entered/selected by the user.
- View: link to the view
- FieldGroup: link to the field group
- Field: link to the field
- Tracing/active fields: updated, createdBy etc.
Note, only one of View, FieldGroup and Field should be set.
Template
A template has the following fields:
- id: primary key
- Module: the module to which the field group belongs
- Name: unique name within the module
- Description: free format description
- Template File: the actual implementation of the template
- Tracing/active fields: updated, createdBy etc.
Datasource
A data source has the following fields:
- id: primary key
- Module: the module to which the field group belongs
- Name: unique name within the module
- Code: a unique and stable code which can be used inside the client
- Description: free format description
- Tracing/active fields: updated, createdBy etc.
- Entity: if the data source represents an Openbravo entity
- Class: a javaclass implementing the datasource
View Handler
A view handler has the following fields:
- id: primary key
- Module: the module to which the field group belongs
- Name: unique name within the module
- Description: free format description
- Tracing/active fields: updated, createdBy etc.
- Class: a javaclass implementing the view handler
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:
- by modeling views in one concept it is easier to develop generic templates
- the generation infrastructure is much easier to implement with one generic concept than with many different implementations in different tables.
- easier to be extended/customized by modules: modules can add new templates and new view types and their related features. The view types are directly usable for existing view-field definitions.
- it is easier to define compound views, as everything is a view it is not that difficult to define a compound view which can contain several other views. A compound view is for example a form with tabs with child grids.
Future extensions/Discussion items
- The above model does not yet contain a toolbar/menu concept. This should be added shortly to support things like an editable grid.
- The idea is to add compound views, a view consisting of multiple other views. The proposed model is well suited for compound views (as everything is done through a central concept: the view). The more difficult part is how to explicitly define/model interaction between views within a compound view. This requires some more study.
- The current model does not define client side dynamic behavior (disable fields based on input of other fields, etc.).
- Global features; currently features are linked to a selected view type. It can make sense to also have global features. For example one which define how to visualize a date field. If the date field template is included by many view templates then it makes sense to make the features used in the date template global (so not linked to any view type but selectable by everyone).
- The field definition has to be extended to support things lile displaylength, displayformat, editformat, validation. The question is if these concepts (formatting and validation) should be defined as javascript calls, or that they need to be extracted out to separate tables.
- Discussion: should data source and view handler be combined in one class?
- Filtering can be made more advanced
- Add parameters to the data source and view handler so that one java class can be re-used by multiple data source/view handler definitions (and pass different parameter values)
- A module can add view types, fields, fieldgroups. A nice other module extension would be if a module can override a template implementation without overwriting the original one. In this way a module can provide a new template implementation which is then used automatically by all views