Projects:Dal Translation Support

Introduction

This page discusses changes to the DAL and related concepts to support the translation concepts in Openbravo in a better and more smooth way. This to help the Openbravo application developer.

In Openbravo several tables have a related translation table. For example the AD_Field table has a translation table AD_Field_Trl. The translation table is used as follows, when a translation of a field is required the following is done:

• the ad_field_trl is searched for a record for the current user language
• if not found then the values in the ad_field table are used directly

The reference from a translation table to its parent table is always an isParent association. So the AD_Field_Trl has a column AD_Field_Id which is marked as isParent == 'Y' in the Application Dictionary. This means that in the DAL generated entities the Field entity has a list of FieldTrl records (see the method getADFieldTrlList in the Field generated entity).

Currently when in the DAL one needs to obtain a translation for an object, the developer has to retrieve the user language id and query for the translated objects and do manual filtering. This is cumbersome and leads to double code. This proposal tries to improve this.

The proposed solution consists of several parts:

• Explicitly identify the Translatable entities and the Trl entities (the entities which contain the translation)
• Create a interface definition for Translatable and Trl entities and let the generated Translatable and Trl entities implement this interface
• Use the hibernate filter concept to automatically filter queries for Trl objects and to filter the list-association from the parent entity to the trl entity.
• Make this filter concept configurable so that it can be enabled or disabled on request

Explicitly identify Trl entities and adding an interface to generate entities

To develop a framework for supporting Trl entities it is needed to identify them. This is also done for other interfaces (like the audit info, active field, organization and client). The first step is to identify that an entity is a Trl entity. The following heuristic is proposed:

• the table name ends with _Trl
• there is at least one column/property with isParent is true
• there is a ad_language_id column and a languageid property
• there is an istranslated column/property

Each entity which is identified as a Trl entity will implement the Trl interface. The trl interface implements this method:

• getLanguageId()

The above talks about the translation entities themselves (the AD_FIELD_TRL table for example). It also makes sense to explicitly tag the translatable entities (for example the AD_FIELD). The translatable entities can be identified because they have children with a name consisting of their own entity name with the postfix Trl.

To support translation in user code a translatable entity will implement an additional interface with one method:

• getTranslation()

This method returns a copy of the instance with all the relevant fields translated.

Note, an additional change, for a translatable entity the getIdentifier() method should be enhanced to always return a translated identifier.

The above interfaces can be automatically added when generating entities and the underlying/supporting code can be implemented generically. This means that the translation concepts described here also automatically apply to modules.

Summary of changes

• The in-memory model builder should be enhanced to automatically identify Translatable and Trl entities.
• The entity generator has to support adding the Translatable and Trl interfaces.
• Generic code has to be implemented to support creating a translated version of an object.
• The hibernate mapping generator has to support generating filters.
• The DAL has to be enhanced to support setting these filters using the OBContext information.
• Testcases have to be added to check the above implementations
• DAL and Developers Documentation has to be updated.