ADF Lifecycle

The ADF Lifecycle provides support allowing a web page to interact with ADF Model data bindings. The lifecycle calls the correct binding container needed for a JSP or UIX page, updates values in the binding container's bindings if necessary, and
prepares the data to be rendered. The binding container stores this data locally before rendering the page.

Implementations of Lifecycle should be thread-safe and use the LifecycleContext object as the place to store any per-request state they may need.


ADF Lifecycle phases:

1. initialize
This phase initializes the values of the associated request, binding container and lifecycle. The method that is used from the Interface Lifecyle for this purpose is :

initializeMethodParameters(LifecycleContext lcContext, oracle.jbo.uicli.binding.JUCtrlActionBinding actionBinding)
This method is invoked before any ControlBinding or custom method is being executed.

2. prepareModel

This phase prepares and initializes the Model. Page parameters are set and methods in the executable section of the page definition of the ADF page are executed. The interface LifeCycle method used :

prepareModel(LifecycleContext lcContext)


3. applyInput
This phase handles the request parameters. These may come by adding the request parameters in the URL or as a result of HTML form post action. A list of events is build using these request parameters. These are actually mapped to the bindings in the pageDef. This phase resolves the list of request parameters bind to attributes in the page def. This results into a list of updatedValues which is used in Update Model phase.

The interface LifeCycle method used :

buildEventList(LifecycleContext lcContext)
Builds the list of events with their possible associated action binding from the request parameters.


4. validateInput

This phase validates the list of values built in the Apply input values field with model.

5. updateModel

This phase updates data model with the list of values created in apply input values phase.

The interface LifeCycle method used :
processUpdateModel(LifecycleContext lcContext)
Update the data model with values submitted in the request.



6. validateModelUpdates

This phase validates the Updates in the previous phase by calling the associated lifecycle's binding container .
The interface LifeCycle method used :

validateModelUpdates(LifecycleContext lcContext)
Forces model-level validation to occur.

7. Process Component Updates

This phase handles any events in the list built during the apply input values phase. Named events as well as all the events tied to the databindings created in the pagdef are handled in this phase.

The interface LifeCycle method used :
processComponentEvents(LifecycleContext lcContext)
Handle any events in the action binding list previously built in processUpdateModel using the buildEventList method.

8. Metadata Commit

This phase commits the runtime metadata changes to the model. This phase is always executed before prepare render phase.


9. Prepare Render

This is the final phase where page is sent for rendering. prepareRender event is sent to all the registered listeners. This notification signals bindings to prepare or process the data for rendering. Binding container is also refreshed. This helps
in updating any changes that happened during validation phases.



References :
- Lifecycle (Oracle Fusion Middleware Java API reference for Oracle ADF Lifecycle)

- Phases in ADF LifeCycle

What are ADF business components and which component provides transaction management?

A challenge every Java developer developing applications using data from a database faces is mapping Java objects to relational tables, managing transactions and locking, and ensuring adequate performance. There are many frameworks that help us handle this, without us needing to build everything from scratch. The open source community has produced a large number of more or less complete and robust frameworks for working with databases and Java objects. Oracle's solution is the Oracle Application Development Framework Business Components.

The main components of the ADF Model layer are:

1. The Entity objects or EO's
2. The View objects or VO's and
3. Entity Association's
4. View Object ViewLinks
5. The Application modules or AM's
6. The Business Component Tester or AM tester

The EO/VO is similar to Object relational mapping elements.
So, in essence, EO/VO provide a standard way of interacting with database tables and serve as the data model source.

The Entity Object

An EO represents a table in simple terms. It defines the table's attributes, the data types, validation on the data, the primary keys and the entire business logic that needs to be defined for pushing data into the target table.


The View Object

The view object can be based on EO's, which are similar to SQL queries used to extract data, or it can be programatically populated, or with a static list.

However VO's based on EO's are most used option. While a few validations can be done even at the VO level, it's better to have business logic on the EO's as this will help provide a central point for all VO's dependent on them.


Associations and Viewlinks

They define the join or the link among EO's and VO's. Associations defines link between EO's. They can be considered as PrimaryKey/ForeignKey relationships between tables. They define the Join conditions.

A viewlink defines the link between VO's and can be based on an association or on attributes.

The Application Module

The application module packages the VO's and serves as the data control.The AM creates and manages the database transaction for ADF Model layer. It is the Application Module that exposes the data needed by the client. So, for an end user, the interaction and transactional capabilities are provided by the application module.

The Business Component Tester

The most used component of the model layer is the tester. It can be run to check the data model that is implemented. This serves as the first line of defense to see if data is exposed as desired, without the need to create a UI.