0 
0 Last week I have been teaching a two day workshop on customization – one of the most powerful framework facilities in ADF. Customizations allows you to create a set of modifications (or even multiple sets of modifications) on top of a base application. The behavior and appearance of the application can be fine tuned to the specific needs of a site (or instance) of the application, or even to the desires of specific user groups on such a site. Especially for ISVs who develop their products using ADF and who would like to create and ship a single version of the application yet allow customers during implementation to do fine tuning according to local requirements, customization is fantastic feature. It allows the creation of customizations that are separate from the core code and that will survive new releases of the base application.
In future blogs, I will tell you more about customization. In this article, I will focus on a specific aspect of customization of ADF applications that may not be as straightforward. It concerns the definition of the RowImpl class for an Entity Object (or any Java Class referenced from ADF BC components).
Our specific need is that the application ships with an Entity Object that will do its built in locking behavior – executing a select for update of against the underlying table. However, in our specific case, the underlying table is in fact a complex view – and a select… for update of against a complex view is not supported. So we need to override the default locking behavior, by implementing our own lock() method in the RowImpl class for the Entity Object (see for example : http://stegemanoracle.blogspot.dk/2006/03/using-updatable-views-with-adf.html). That means we need to customize the Entity Object and set our own class as the RowImpl class. These are the steps:
1. Create a class that extends from TranslationImpl and overrides the lock method:
package mypackage;
import oracle.jheadstart.model.adfbc.translation.entity.TranslationImpl;
public class ExtendedTranslationImpl extends TranslationImpl {
public ExtendedTranslationImpl() {
super();
}
public void lock()
{
// let’s assume we can live without lock altogether.
}
}
2. Run JDeveloper in Customization Role
3. Locate the Translation EO
4. Open the EO editor for EO Translation.
Make a change to the property Schema Object in the Property Inspector
5. This will create the customization file:
6. Edit the customization file Translation.xml.xml:
– remove the attribute change for DBObjectName
– add the following attribute change:
<mds:attribute
name=”RowClass”
value=”mypackage.ExtendedTranslationImpl”/>
Now when you run the application with site level customizations active, the ExtendedTranslationImpl will be used and the lock will not attempt the illegal for update of against the complex view JHS_TRANSLATIONS.
Related posts:
OOW 2009: Castle in the Clouds: SaaS-Enabling Oracle ADF Faces Applications 
Adding customization (or context sensitivity) to boilerplate text from database backed resource bundles in ADF applications 
Live update of Resource Bundle from within running ADF application 
ADF: undo the user’s page personalizations – query and manipulate MDS 
ADF: Cloning personalizations between users – read and write MDS Customization documents
