ERP 2.50:Developers Guide/Concepts/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:
- It allows to implement in a generic way rules that apply to all AD components like security, navigation and others.
- 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
The most standard usage of AD_Model_Object and AD_model_Object_Mapping is to define Servlets linked to Application Dictionary objects and their mapping.
When a tab, a form, a report or a process is defined in Application Dictionary, automatically a new entry in AD_Model_Object and AD_model_Object_Mapping is created pointing to the Java class that implements that object and to the mapping for that Servlet. The module assigned to the new record in AD_Model_Object is the same as the Application Dictionary object it links to. Whereas Java class and mapping for manual objects (forms, reports and processes) are just a suggestion that can manually modified to adapt it to the actual implementation, the ones for generated tabs shouldn't be manually modified. The only consideration to these modifications is to maintain the same directory depth in the mapping in order to preserve relative html links.
Other Servlets
As explained in Model - Implementation concept section there are some occasions 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:
- Object.Name: jdbc/openbravo
- Object.Java Class Name: javax.sql.DataSource
- Parameters.Name: auth
- Parameters.Search Key: Container
What is new
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 has been 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.
| Languages: |
ERP 2.50:Developers Guide/Concepts/Skins look and feel | ERP 2.50:Developers Guide/Concepts/Deep linking