View source | View content page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Show collection (0 pages)
Collections help


Projects:UI Technology/MyOB



This document contains the design for the MyOpenbravo (MyOB) functionality.

MyOB is the first tab in the multi-document interface. It is the starting page for a user when logging in. It contains widgets which provide information from different information sources (Openbravo, news feeds, igoogle gadgets etc.).

A user can configure the MyOB tab by creating and organizing widgets.

Myob pro.png

Widgets Key Aspects

Some key aspects:

MyOB and Widget Functionality

Multi-column display

Widgets are shown in columns. Within a column widgets are vertically organized. For an example of a multi-column display see the Smartclient Portal example.

Ui portal example.png

The number of columns can be set in the user preferences of MyOB (see the user preferences section below). Note: in a first release it is also acceptable to support a fixed set of 2 columns. Preferably in the underlying implementation a flexible number of columns should be taken into account.

Columns are horizontally resizable.

Remove and Add widgets

A user should be able to hide and show widgets. This means that there should be a global dialog which shows the available widgets to the user. The user can then drag/drop widgets to the desired column.

A user can remove a widget by opening a popup dialog and clicking 'delete this widget'. A widget can be re-added again from the list of available widgets on the left (see screenshot below).

Parameterized Widgets

Widgets can be parameterized, meaning that the user can enter values for these parameters and in this way influence the widget calculation/visualization. The parameter dialog can be opened from the widget header ('edit this widget').

Myob pro edit.png

The above screenshot also shows a widget in edit mode, see the RSS Feed widget in the bottom.

A widget can have any number of parameters. The parameter types are defined in the widget definition, the following is defined for each parameter:

A user can change a parameter through a dialog which can be accessed through the widget.

Organize widgets

Widgets should be draggable:

In addition a widget can be moved up/down, to the right or left, through the dialog which popups from the header (see screen shot above).

The widget organization is persisted when changes are made so that when the user returns the widget organization (column, size and location within the column) is restored.

Different types of widgets

URL based widget

The url widget loads its content from another website using an url. The url can be anything, the loaded content is not checked or converted, it is displayed as is within the widget.

The url of an url-widget can contain parameters which are substituted at runtime. The parameters can be taken from the user parameters (see previous section) of that widget or can be retrieved from the context (userid for example).

Html/iGoogle Widget

The Html widget basically shows a piece of html which is maintained in the widget definition. This type of widget also supports the iGoogle gadget concept which is implemented by incorporating javascript in the body of the html.

Query/Templated Widget

The query/templates widget is a widget which reads information from the database (or another data source) and displays the result to the user. The widget consists of 2 parts:

The widget parameters, set by the user, are passed on to the template so that it can make use of them when processing the data.

Computed Widget

This type of widget is completely developed in java. It allows the developer to make use of the complete Openbravo system to compute the information (html) shown in the widget.

Multiple Widgets of the same Type

As widgets can be parameterized it is perfectly fine for a user to display the same widget (for example a sales order tracker) multiple times, as each widget instance can have different parameters.

Creating widgets at runtime

A user should be able to create a widget on the fly at runtime. The list of available widgets is shown on the left in MyOB (see screenshots above). The list is based on the widget role access table (see the data model section). The order in the list is based on the sortno column in the widget definition.

The user can create a new widget in two ways:

In both cases the user needs to enter the information needed by the widget. This means that a widget needs like a creation dialog which makes it possible for the user to enter the required information (an url for a newsfeed for example).

Instead of supporting a custom (complex) creation dialog another approach can also be followed: use the concept of widget parameters. One or more parameters can be flagged as mandatory. When the user creates a widget the user must first fill in the mandatory parameters before the widget is actually created. For example, when a user drags a newsfeed widget in a column he/she needs to enter the url of the newsfeed.

Common widget instance information

When a user has created a widget in MyOB there are two fields he/she can set for the widget:

These are stored as parameters for the widget instance.

Default widget set by role/complete system

It should be possible to define a default set of widgets to show when a user logs in for the first time. It makes most sense to define this information on role level.

It should be possible to configure the set of visible widgets in detail (parameters, which widgets are shown in which column). To facilitate this the idea is that an authorized user can log in and store his/her current configuration for a specific role or on system level.

To support this the following needs to be supported:

User Preferences

As indicated by the previous sections, somewhere in MyOB it should be possible to open a user preferences dialog which make it possible for the user:

When the user reduces the number of columns then the columns are removed first on the right side and the widgets in that column are removed (in a later version we can support automatically moving over widgets to other columns).

When increasing the number of columns, these are added to the right.

When changing the number of columns the system should use a practical/sensible approach for resizing the remaining/new columns.

Community versus Pro edition

The MyOB functionality will differ depending on if the Openbravo version is a community or a pro edition:

Myob community edit.png

Other functionality aspects

Some other functionality aspects which need to be taken into account:

Widget implementation

This section discussed the main code components of the solution. It discusses both the client as well as a server side implementation.

Client side: MyOB Manager

The MyOB manager manages the complete MyOB tab. This object is responsible for creating the content of the MyOB tab:

When the user starts the application and the MyOB tab is shown then the MyOB manager goes through the following steps:

  1. read the MyOB configuration from the preferences: this includes the number of columns and their widths.
  2. read the current set of widgets for the user. The widget instances are either defined on user, on role or on client level.
  3. for each widget instance, create a client side representation and pass in the widget instance configuration (read from the database) and widget parameter values. The client side widget instance is then responsible for creating its content by calling the corresponding server side instance. The client side widget window is then created and placed within the MyOB tab.

Then at runtime the MyOB manager takes care of:

The client side MyOB manager is responsible for both the client-side dialogs to support these functions as well as sending configuration changes to the server to persist them in the database.

When a widget has mandatory parameters then the user must set these before the widget can be instantiated/shown. For this the MyOB client manager must be capable of:

The flow for creating a new widget is then as follows:

  1. the user selects a widget to create
  2. the MyOB client manager checks if there are mandatory parameters
    1. if so then these are used to create an input form
    2. the user enters the parameter values and presses save
  3. a request is send to the server to create a widget, the request also contains the mandatory parameter values
  4. the server creates the widget instance record and stores it in the database together with the parameter values
  5. the widget id (of the new record) is sent back to the client
  6. the MyOB manager receives the widget id and uses this to create the widget (this is the same approach as creating widgets when logging in)
  7. the widgets in the target column are re-ordered and resized to make room for the new widget
  8. the MyOB manager stores the new configuration (size and ordering of widgets) on the server.

There is a special scenario which should be covered by the client and server side MyOB manager. When a user logs in then it is possible that his/her widgets are not defined on user level but on role/client level. When the user however then changes the configuration (change columns, resize widgets, sets parameters) then the widget configuration (settings, instances, parameter values) should be stored on user level. So there is an initial situation where all the widget instances and their configurations are created for a user.

An alternative choice can be to copy the set of widgets from role/client level to the user level when a user logs in for the first time.

Client side: Widget Class/Widget Window

The client side widget class is responsible for creating a widget window and fill its content. When the widget class is instantiated it reads the widget definition from the server and then creates the widget window. The widget content is read from the server and displayed within the widget window.

A widget window has a common part which is the same for each widget. This part provides these functions:

A client side javascript class should be created which serves as the default implementation of a widget. When creating an instance the client side class will receive a widget definition with the following information:

For visualizing the widget this class should create a window which:

Note that a widget definition can define its own client side class to use for the widget. This custom widget class should in practice always extend the default widget class.

Server Side: Widget Class

The server side widget implementation class is specified in the widget definition in the widget table. The class should implement a specific interface defined by the to-be-defined abstract super class: Widget. The interface defines these methods:

The above bullet mentions that the html generated by the widget is valid html. A choice can be made to always have a generic html part (the head for example) and let the widget only generate the body of the html.

Server Side: Widget Manager

On the server side there should also be a widget manager class which supports actions for the complete MyOB tab, for example:

Widget Data Model

This section describes the tables of the MyOB solution. All the tables require a maintenance window (in classic OB style for now).


The OBMYOB_Widget table stores the widget definition. Modules can provide their own implementation and additional parameters by adding child tables.

The OBMYOB_Widget table is a client/system table with the following columns:


Widget Parameters

The widget parameters are stored in a table (OBMYOB_Widget_Parameter). This table has the following characteristics:

This table has the following columns:

Modularity specifics:

Widget Preferences

The number of columns in MyOB is stored by user. This information is stored as a user preference in the preference table. There are client side utilities which facilitate getting and setting this preference:

A new list reference value should be created for the 'Property Configuration' reference. The name of this list reference value should be used when getting/setting this preference.

Widget Instances

The OBMYOB_Widget_Instance table holds the instances which have been created for/by the user.

The role and user fields are used to support the concept of default widgets. If they are both null then this is a widget instance which is available for users which do not have widgets defined on user or role level.

The records in this table are typically created by the system and not through manual actions.

Widget instance parameter values

The OBMYOB_Widget_Param_Values stores the values entered by the user for the parameters of the widget. It has the following columns:

The records in this table are typically created by the system and not through manual actions.

This is a client/system table.

Widget By Role

Widgets are enabled by role, so different roles have different widgets which can be created by a user. The content of this table defines which 'add' links are shown in the MyOB tab on the left.

To define which widgets are available for which role the table OBMYOB_Widget_Role_Access is introduced. This table has the following columns:


The widget by role window should be implemented as a child tab in the widget window.

Widget Types and the data model

This section describes how the different widget types are modeled in the above datamodel.

URL Widget

The url widget is a widget which reads the content of the widget from another website using an url. The url is defined as a mandatory widget parameter. This means that when a user creates the widget on the client that he/she needs to enter a url for it. The url can itself contain parameters which are substituted at runtime.

A specific widget implementation should be developed which resolves the parameters in the url and then create the url which is used to retrieve the content of the widget.

When implementing this widget class a choice should be made if the url is called from the client directly or that the server calls the url and sends the result to the widget.

Note that the newsfeed widget can be implemented using this same approach (defining a mandatory url parameter).

HTML Widget

The HTML widget has its content defined as a valid piece of html. The html is defined using a widget parameter. This widget supports the igoogle gadget which consists of a piece of javascript which is placed in the html.

Query and Templated Widget

This widget consists of two main parts:

The query/template widget specific information is stored in a child table of the widget table: OBMYOB_Templated_Widget.

This table has the following columns:


The window of this table should be implemented as a child tab in the widget window.

Example Widgets

The initial implementation of MyOB should contain a number of examples widgets:

Open/Discussion Topics

Retrieved from ""

This page has been accessed 4,599 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.