My strategy & consideration for establishing internal ADF JDeveloper 11g best pratices

My primary focus is architecture and before getting started with the next version of jdev, I will be investigating the new features that focuses around reusability. Also, conventions are  listed here for later review.

References I used for consideration

An Oracle article on  (mostly)  ADF BC Standards

Another great presentation Chris Muir authored

Frank & Lynn’s Oracle Fusion Developer Guide

fusion developer guide

ADF Insider Essential youtube

Lynn’s slides on team at 2012 OOW

ADF Arch Patterns

ADF Architecture Square

My original post regarding structure.!topic/adf-methodology/58nVV6sDscs

Case study by Grant Ronald.

Avrom’s document on reuse

The following items outline arch considerations for our next 11g app.

Business components:

Create BaseVos for:





Use base vos with view criteria as mentioned by dede

As the ADF Code Guildine mentioned (p15) create wrapper method for accessing the transaction (DBTransactionImpl) and to call close.

Backing Beans

as mentioned by the OFDG, implements Seralizable and extends super class.

Naming of VOs (Updatable vs Readonly)

If a vo is based on eo, it will be named with UVO suffix otherwise it will just have VO

Project Structure

Projects will be named with layer type prefix followed by biz name suffix.

This will enable developers to identify project quickly.

Ensure View Controller projects have unique package so databindings.cpx do not have a naming conflict.

ADF Faces Templates:

Create them in a folder that cannot be accessed via url.

Establish folder & naming convention. e.g., web-inf/uitemplates

Data bound templates can be used to call “super class” methods on the binding. I brought this up a while ago over at the OTN forums, at the time, no declarative solution was availble for 10g. Within the post, Chris & Frank suggested to use this solution for 11g.

Non data bound templates or layouts.

If the template has a manage bean, create interface for both it and classes which consume the template to implement. This design was described by Frank here:

I really like this approach as we also use a similar practice in our 10g app. Pages that are supported with backing beans implement interfaces that dictate behavior. eg. A page for read only info vs a page with updateable info. In addition to the interface, developers also extend superclass which has a set of common methods that a particular page needs. Frank’s presentation includes this in a super class but the difference between 10g and 11g code is that his 11g version has a getBean() method which basically gets the current bean from a attrb scope var. In our 10g case, the backing bean is set on process scope which a superclass can access. Another nice feature in 11g is that the implementation is enforced at design time, the consuming page which uses the template is validated at design time to check for assignment of the superclass bean.

Implement the following!

Deploy templates as ADF Library.

ADF Task Flow Templates:

Create them in a folder that cannot be accessed via url. e.g., web-inf/taskflowtemplates

Establish folder & naming convention.

Page fragments can be used at first if unsure and refactored later on into TF templates.

BTFs that share the same exception handler should be based on a task flow template that routes exceptions to a common handler.

Declarative Components

need to be created in it’s own project

need naming convention.

Implement methods in OFDG  p496 – getIteratorBinding()

Implement methods to access facets from declarative component OFDG p496 – getCustomAddedButtons()

Component ID names

Declarative component ID names

Template component ID names

De-coupled Deployment

One of the biggest flaws of rollouts in our current 10g app is it’s an all or nothing event. For our next ADF app, I need to structure the project in such a way that modules can be deployed individually.

Task Flows

Since an application UTFs are combined at runtime into one file (OFDG p106-107), we need to have a naming convention for uniquely identifying UTFs.

UTFs can be used to create top level unrestricted app flow (menu) and bookmarks.

BTFs should be used for CRUD operations and biz cases which only has a single POE.

BTF parameters should be bound to manage bean properties. This was mentioned by frank because you can document with javadoc and it can be discovered at design time.

Establish convention to distinguish BTFs and UTFs (e.g., *-btf.xml, *.-utf.xml). Also prefix to quickly associate it with a biz process.

Implement Util class with programmatic access to scope (OFDG p128)

Include diagram of scopes in action for internal documentation (OFDG p129&131)

Implement TF Template with exception handler and use it as POE of all modules and potentially authentication token checking.

For Biz Logic that could potentially be reusable, BTFs should be created with input parameters. No assumption on DC sharing and should be looked as as an encapsulated class.


Developers should not use application nor session scope. On our team working with 10g, this was very much like the wild wild west and we eventually lost track of what values were set.

Declarative components should be bound to backingbean (not request as in 10g).

Code templates

Aggregate common code from developers to create common java code templates.


Jump start the dev process by using ADF UI Shell!

ADF Libraries

Seperate UI and BC adf libs.

Naming conventions

Mark library artifacts to private if they are not meant to be viewed.

Reconize the following:

Code Versioning, integration & deployment

Research how to configure high availability production deployments using the feature mentioned by Chris in Angel in ADF Architecture. He said that there is a way to retain existing user sessions in the old version while have new users routed to the new deployed app.

research how to perform automated deployments from svn repo.

See this vid from ADF Insider Essentials


Use catalog in resource palette to group adf libraries.

Questions (bring to OOW 2012):

Identify use cases for shared/not shared data controls. Multiple Root app modules would be needed to separate the transaction.

In Enterprise Java Desktop development, it is good practice to establish a base framework work superclass, ie FrameworkJTable. Organizational developers would then create their own subclass of this instead of JTable. The idea would be to allow the UI architect to gradually add to the FrameworkJTable or refactor it to eventually build up standards. Can this be done using declarative components? Should all developers start using a declarative af:table from the beginning? Similar to how developers can do this with Base Biz Components.

What is the best strategy for seperating adfc-config.xml? In 10g, we have multiple face-config.xml (each file corresponds to a view layer module, grouped by JSPs in a folder)which are then appeneded together in web.xml. Perhaps one way is to separate by purpose, e.g. beans, flows, converters, validators.

If we use the UI Shell to kick off our dev, can we later easily refactor our app to use custom layout?

What are the memory & performance overheads associated with templates,fragments,regions, btfs, multiple projects?

In a multiproject design, where should the RootAM be placed?

Ask other people about how they design their release/integration process.

About wesfang
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s