ADF BC: How to customize the RowImpl class for an Entity Object as site level customization

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
clip_image002

4. Open the EO editor for EO Translation.

Make a change to the property Schema Object in the Property Inspector

clip_image004

5. This will create the customization file:
clip_image006

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”/>

clip_image008

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.

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

Leave a Reply