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

Model Object Mapping

Contents

Introduction

Web Applications (as Openbravo ERP) have a Deployment Descriptor. It is actually a xml file (web.xml) which defines everything about the application the server needs to know (servlets, mappings and other components).

Openbravo ERP generates this file in compilation time with the information stored in AD_Model_Object and AD_Model_Object_Mapping tables. This document explains these two tables.

Model - Implementation concept

AD_Model_Object is a table in Openbravo Application Dictionary to link Application Dictionary components and the class (servlet) that implement that object. So this table is a mapping between the logical side (AD components) and the physical side (classes). It is useful for two main reasons:

  1. It allows to implement in a generic way rules that apply to all AD components like security, navigation and others.
  2. It is the mechanism to automatically populate the web.xml file where classes (servlets) are declared. The AD_Model_Object_Mapping is an utility to create the mapping entries in the web.xml file.

There is a few number of exceptions to this description: some servlets that are deployed in Openbravo context but are not linked to any AD component, such us the DataGrid or the AuditInfo servlets. They are invoked from manual or standard components (windows, forms, etc.) through http requests by hardcoding its url-mapping in the request. It can be interpreted still as a mapping of actual classes that implement a functionality that is not described in current Openbravo model, although it may be in the future.

The following sections explain how different elements are defined.

Servlets

Application Dictionary Objects

In previous versions of Openbravo, when a tab was created, new Model Objets were created for it. This no longer happens, as the web.xml entries for tabs are automatically added to the web.xml file directly when the compilation is done, without reading any info from the Model Object tables.

Other Servlets

As explained in Model - Implementation concept section there are some situations where it is necessary to define a Servlet which does not implements an Application Dictionary Object. These cases are defined in Application Dictionary || AD Implementation Mapping window. Selecting in Object tab the Servlet Object Type, setting the Java class with the Servlet implementation and adding in the Mapping tab the mapping to access the Servlet.

Filters

Filters can also be defined in Application Dictionary || AD Implementation Mapping window. Select Filter object type, and set the Java class that implements the filter. In Mapping tab add the url patterns for the object to be filtered, and in case the filter receives any parameter set them in the Parameters tab with the values they will have. To retrieve the parameters values in the implementation use implement init method like follows:

 
  public void init(FilterConfig config) throws ServletException {
    encoding = config.getInitParameter("requestEncoding");
    if (encoding == null)
      encoding = "UTF-8";
  }

Listeners

Listeners are defined in Application Dictionary || AD Implementation Mapping window with type Listener. In this case it is not necessary to define Mapping nor Parameters, just the java class implementing it. Take into account that listeners must be executed in certain order, this order is defined by the Sequence number field.

Resources

Resources are defined in Application Dictionary || AD Implementation Mapping window with type Resource.

Let's see the following example in web.xml:

 
  <resource-ref>
    <description>Oracle Datasource example</description>
    <res-ref-name>jdbc/openbravo</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

This resource is defined by assigning the following values to the following fields:

Modularity and the Model Object Definition

Openbravo Modularity aims to allow through modules the deployment of any type of optional content in an Openbravo instance, including additional entries in the web.xml file of openbravo context. This is done through the AD_Model_Object table. Developers can create entries in this window not linked to any AD component. To support any type of web.xml content (servlet, listeners, filters, etc.) a new column is added to the AD_Model_Object to represent the type of web.xml entry that the developer is adding. They can also declare a set of mappings for the entry and a set of parameters if needed.

The module of a AD_Model_Object entry is calculated with the following rule: if it is linked to any AD component then the module is the one assigned to that AD component, otherwise the module is the one assigned to the AD_Model_Object record itself. Note that the module for the AD_Model_Object child tables (AD_Model_Object_Mapping and AD_Model_Object_Para) is the same as their parent record.

With this extension the web.xml file in the openbravo context is fully extensible through modules.

In previous releases AD_Model_Object table defined just Servlets, other objects in web.xml file were added directly to its template. In r2.50 model was extended to allow definition of other objects (filters, listeners, resources and Servlets not linked to AD elements) adding the AD_Model_Object_Para table and the Application Dictionary || AD Implementation Mapping window to manage it.

Retrieved from "http://wiki.openbravo.com/wiki/Model_Object_Mapping"

This page has been accessed 2,625 times. This page was last modified on 12 July 2011, at 08:13. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.