Difference between Managed Bean and Backing Bean

First of all backing beans are not entirely different from managed beans. Very unpopular thing to say, but it’s true. Backing Bean is also a managed bean with some specific settings.

 

What is a managed bean?

Managed beans are Java classes that you register with the application using various configuration files. When the JSF application starts up, it parses these configuration files and the beans are made available and can be referenced in an EL expression, allowing access to the beans' properties and methods. Whenever a managed bean is referenced for the first time and it does not already exist, the Managed Bean Creation Facility instantiates the bean by calling the default constructor method on the bean. If any properties are also declared, they are populated with the declared default values.

What is a Backing Bean?

Backing beans are managed beans that contain logic and properties for UI components on a JSF page.

The key point here is: It has a one-to-one relationship with a single JSF page.

It exposes setter and getter methods for the components contained on the page.

When you create your JSF page, if you choose to automatically expose UI components by selecting one of the choices in the Page Implementation option of the Create JSF Page dialog, JDeveloper automatically creates a backing bean (or uses a managed bean of your choice) for the page.

For each component you add to the page, JDeveloper then inserts a bean property for that component, and uses the binding attribute to bind component instances to those properties, allowing the bean to accept and return component instances.

Let’s see how to create a backing bean and what Happens when we create one.

·         Create a new Jspx page, Expand “Page Implementation” and click on “Automatically Expose UI Components……..”

·         See the structure of the blank page created. Notice the components present.

·         You can find properties present in the bean for these components.

·         Then drag adf components like panel box and input button to the page.

·         You can see that JDeveloper created two properties for the above created components.

Understanding Transactions in ADF Taskflow

In ADF transactions are defined and owned by the underlying business service implementation used within the Model layer of the application. As example ADF Business Components take out connections and transactions with the database. Such services are then exposed to the View Controller layer through an abstraction known as a Data Control for the View Controller to work with.

As our application can utilize multiple data controls, the ADF Controller (ADFc) through the facilities provided by the task flow transaction and data control scope options, allow one or more data controls to be grouped together and committed or rolled back as a group.

The underlying business services still own the transaction and ultimately execute the commit and rollback operations, but the ADF Controller defines the boundaries of the task flow transaction, namely where the transaction starts and stops and which data controls are involved.

For the bounded task flow transaction option itself there are only 4 options:

·         "<No Controller Transaction>"

·         "Always Begin New Transaction"

·         "Always Use Existing Transaction"

·         "Use Existing Transaction if Possible"

Data control scope:

·         Isolated

·         Shared (Default)

Shared Scope

When a task flow defines a shared data control scope, this implies the task flow will attempt to share any instance of a data control (and by implication it's state) with the task flow's caller if the data controls have the same definition, rather than creating a new instance.

Isolated Scope

If a task flow defines an isolated data control scope, even if both task flows use the same design time data control definition, at runtime each task flow will have their own instance of the data control.

Data Control Frame

The Data Control Frame is the magic behind how this works. Essentially each task flow has the potential to have its own data control frame containing a list of the used data controls. A data control frame is created at runtime for your application's unbounded task flow and any isolated data control scoped bounded task flow.

However when a bounded task flow specifies a shared data control scope the current task flow uses the data control frame of the caller rather than creating its own, giving the called task flow the chance to share data control instances attached to the frame.

 Alternatively if the bounded task flow specifies an isolated data control scope, a new frame will be created and a new instance of any data controls used by the bounded task flow will be attached to this new frame.

Now let’s see the different options available in transaction management in Taskflows:

Always Begin New Transaction

It is used to start a new transaction in your application. Typically this option is coupled with the isolated data control scope and a new separate data control frame.

If a bounded task flow does start with a new transaction, when it wishes to complete it must call a task flow return activity commit or rollback. These call the underlying commit() or rollback() operations on the associated data control frame, essentially committing or rolling back all data controls attached to the frame.

Always Use Existing Transaction

A bounded task flow that uses the "Always Use Existing Transaction" option is designed to share the transaction of the previous task flow in your application; it will not start a new transaction.

On closing it cannot make use of a commit or rollback task flow return activity, at design time such a task flow return activity will be flagged in error. Only a task flow that starts a new transaction can call these. In this case the "Always Use Existing Transaction" option will depend on its caller to finalize the transaction. Instead the "Always Use Existing Transaction" task flow simply calls a task flow return activity with its End Transaction property set to "<Default> none".

Use Existing Transaction If possible

It is the most flexible of the transaction options and it is a combination of the "Always Begin New Transaction" and "Always Use Existing Transaction" options.

If "Use Existing Transaction if Possible" is used with an isolated data control scope, it operates in the same manner as the "Always Begin New Transaction" with an isolated data control scope creating a new data control frame.

If "Use Existing Transaction if Possible" is used with a shared data control scope its behaviour is dependent on if a transaction is open on the shared data control frame of the caller.

If a transaction is open it has the same behaviour of "Always Use Existing Transaction" with a shared data control scope.

If a transaction is not open, it behaves the same as "Always Begin New Transaction" and a shared data controls scope.

No Controller Transaction

"<No Controller Transaction>" option is restricted in its interaction with the data control frame; it does have a more liberal relationship with its relating data controls and their transactions.

·         Doesn't start a transaction on the data control frame like the "Always Begin New Transaction" option

·         Doesn't check or enforce if a transaction is open on the data control frame

·         Will not call finalize the data control frame transaction by calling the Data Control Frame commit() or rollback().

The established rules still apply for the data control scope though. If an isolated data control scope is specified for the task flow a new data control frame and data controls will be instantiated. For a shared data control scope the previous task flow's data control frame and data controls will be shared.

How ADF Bindings Work

Before Learning about How ADF Data Bindings work, let us have a brief info on the following things:

Binding Context:

The ADF binding context is a container object that defines a hierarchy of data controls and data binding objects derived from the Oracle ADF model layer.

         

Binding Container:

Oracle defines Binding Container as “The BindingContainer contains the Control Bindings for a reusable unit of View technology”. But in simpler words it is a runtime representation of a view technology like pageDefintion file. The bindings are held in a request-scoped map called the binding container, accessible during each page request using the EL expression #{bindings}.

Some of the important methods provided by BindingContainer are:

getAttributeBindings:

java.util.List getAttributeBindings()

Return a list of all AttributeBinding and AttributesBinding in this RegionBinding

getOperationBindings

java.util.List getOperationBindings()

Return a list of all Action bindings in this RegionBinding.

Page Definition File:

Page definition files define the binding objects that populate the data in UI components at runtime. For every page that has ADF bindings, there must be a corresponding page definition file that defines the binding object used by that page. Page definition files provide design time access to all the ADF bindings. At runtime, the binding objects defined by a page definition file are instantiated in a binding container, which is the runtime instance of the page definition file.

ADF Data Control

The application module data control is a thin adapter over an application module pool that automatically acquires an available application module instance at the beginning of the request. During the current request, the application module data control holds a reference to the application module instance on behalf of the current user session. At the end of the request, the data control releases the instance back to the pool.

This optimized interaction allows the bindings to work directly with the application module instances in its data model in the following ways:

·         Iterator Bindings directly bind to the default row set iterator of the default row set of any view object instance. The row set iterator manages the current object and current range information.

·         Action bindings directly bind to either Custom methods on the data control client interface or built-in operations of the application module and view objects.

Different Types of Declarative Bindings

There are three basic types of Declarative Bindings:

·         Iterator Bindings:Simplify the building of user interfaces that allow scrolling and paging through collections of data

·         Value Bindings:Used by UI components that display data. Value bindings range from the most basic variety that work with a simple text field to more sophisticated list and tree bindings that support the additional needs of list, table, and tree UI controls.

·         Action Bindings:Used by UI components like hyperlinks or buttons to invoke built-in or custom operations on data collections or a data control without writing code.

Things to know about using Data Controls Panel

When we use the Data Controls panel, the listed points below are some of the things which get configured:

·         Create a DataBindings.cpx file in the default package for the project(If one does not already exist), and adds an entry for the page.

DataBindings.cpx file defines the binding context for the application. Each DataBindings.cpx file maps individual pages to the binding definitions in the page definition file and registers the data controls used by the pages.

·         Creates the adfm.xml file creates a registry for the DataBindings.cpx file, which allows the application.

·         Registering the ADF Binding Filter in web.xml file. The ADF Binding Filter pre-processes any HTTP requests that may require access to the binding context.

·         Creates the orion-application.xml file and adds a reference to the oracle ADF shared libraries needed by the application.

What is DataBindings.cpx and DataControls.dcx?

DataBindings.cpx file defines the binding context for the application. Each DataBindings.cpx file maps individual pages to the binding definitions in the page definition file and registers the data controls used by the pages.

The DataControls.dcx file is created when you register data controls on the business services. Note that this file is not generated for the Oracle ADF Business Components and Oracle ADF TopLink Mappings data controls. In those cases, the data control obtains the metadata directly from the generated services.

The DataControls.dcx file specifies the factory classes for a bean registered as an Oracle ADF data control. In the case of EJB, web services, and bean-based data controls, you can edit this file in the Property Inspector to add or remove parameters and to alter data control settings.

How Binding Context Works?

When a page contains ADF Bindings, at runtime the interaction with the business services initiated from the client or controller is managed by the application through a single object known as binding context.

The ADF Lifecycle creates the Oracle ADF Binding Context from the application module, DataBindings.cpx and page definition files.

We already know about databindings.cpx file and page definition files which have been explained above.

The Binding Context does not contain real live instances of these objects. Instead, the map contains references that become the data control or binding container objects on demand. When the object (such as page definition) is released from the application, for example when a task flow ends or when the binding container or data control is released at the end of the request, the data controls and binding containers turn back into reference objects.

sources : ADF Fusion Middleware Dev's Guide

How to use refresh property correctly?

 

We all may know what refreshing an iterator is. It is the process in which an iterator binding rebinds itself to a live row set iterator which is tracking the current row of same data collection.

Having a strong knowledge on ADF Life Cycle might help before reading this article. Please read in the provided link.

Now By default, this happens only once, when the iterator is first accessed by the client layer during the life cycle.

To force the iterator binding to refresh its row set iterator earlier in the lifecyle, you can set the refresh attribute on the iterator binding to a value other than the default.

The refresh and refreshCondition attributes are used to determine when and whether to invoke an executable, such as an iterator binding, or an invokeAction.

Different Values for refresh property              

By default, when JDeveloper adds an executable to a page definition (for example, when you drop an operation as a command component), the refresh attribute for the executable binding is set to deferred.

We can change this into the following values:

·         deffered: It enforces execution whenever the binding is accessed the first time. If no refreshCondition value exists, the executable is invoked. If a value for refreshCondition exists, then that value is evaluated as an EL expression, and if the return value of the evaluation is true, then the executable is invoked

·         prepareModel: It will get refreshed during the Prepare Model phase of ADF life cycle.

·         renderModel: It will get refreshed during the Prepare Render phase of ADF life cycle.

·         ifNeeded: During the Prepare Model and Prepare Render phases, only if needed. For iterators, the refresh is considered needed if the binding has not yet been refreshed. To determine if the execution is needed for an invokeAction, the framework compares the current set of evaluated parameter values with the set that was used to invoke the method action binding previously. If the parameter values for the current invocation are exactly the same as those used previously, the invokeAction does not invoke its bound method action binding.

·         prepareModelIfNeeded & prepareRenderIfNeeded: Same as ifNeeded, except that it is executed during the named phase.

·         never: Not valid for invokeAction executables. For iterators, the iterator will never be refreshed. Use when your own code calls getRowSetIterator() on the iterator binding.

·         always: Not valid for invokeAction executables. For iterators, the iterator will always be refreshed (potentially multiple times) during both the Prepare Model and Prepare Render phases, as well as during the Update Model phase.

·         refreshAfter: Use to handle dependencies between executables. For example, you can set the condition so that this executable refreshes after another executable

Important Note – Distinction Between prepareModel & renderModel

prepareModel comes before JSF’ Invoke application phase.

renderModel comes after JSF’ invoke application phase.

So if you want your iterator to get refreshed after the execution of the action listeners then you should use renderModel.

Understanding Immediate Attribute

The immediate attribute is highly misunderstood by thousands of developers. The misconception with immediate attribute is that if we set it as true – “It skips validation”. Well, it is not always true. Let us see how!!

Before reading you should know how JSF life cycle works. For reference you can check out my previous post in this link.

Now in general, the immediate attribute allows processing of components to move up to the “Apply Request Value” phase of JSF life cycle.  But the behaviour of immediate attribute depends on which adf component it has been applied on.

Where Can I use Immediate = true for commandButton ?

Sometimes we might have a form for inserting values for a record. We must need a “Cancel” button there to undo the changes and navigate to some previous page. What we normally do:

·         We clear the iterator from the garbage values. And then navigate our page

We can achieve the same functionality using immediate = true:

·         We can set immediate property of the cancel button as true. When user clicks on Cancel button, all validations are skipped, any entered data is not updated to the model and the user navigates to previous page.

How is this more efficient?

·         It avoids validations and update model phase thus saving time.

·         The iterator doesn’t need to be accessed which again saves memory and time.

Where Can I use Immediate = true for components like inputText?

Setting immediate to true for an input component can be useful when one or more input components must be validated before other components. Then, if one of those components is found to have invalid data, validation is skipped for the other input components in the same page, thereby reducing the number of error messages shown for the page.

What if I have used an inputText with immediate = false but commandButton with immediate = true?

This situation may lead to a problem in the following scenario:

·         The commandButton is calling a method in managed bean. You need to access the data entered by the user in the inputText in this bean method.

·         Now the problem here is, as the immediate property is set as true for command button; the actionListener has been called in the “Apply request Value” phase only. So the data has not been updated to the model. So we won’t be able to get the data from the iterator

How do I get the value in the managed bean then?

In order to get the value in managed bean, you need to set the immediate property of the inputText as true as well.

·         This way the valueChangeListener event for the inputText will be done in the “Apply Request Value” phase itself. Then using the bindings of the inputText we can have the data entered by the user.

Understanding JSF Life Cycle

The JSF lifecycle phases use a UI component tree to manage the display of the faces components. This tree is a runtime representation of a JSF page: each UI component tag in a page corresponds to a UI component instance in the tree. The FacesServlet servlet manages the request processing lifecycle in JSF applications. FacesServlet creates an object called FacesContext, which contains the information necessary for request processing, and invokes an object that executes the lifecycle.

The JSF Life Cycle is represented by the following diagram:

Photo Courtesy: Web User Interface Developer's Guide for Oracle ADF

Let’s understand each phase of the JSF lifecycle:

·         Restore View: The component tree mentioned earlier is established. If this is not the initial rendering, the tree is restored with the appropriate state. If this is the initial rendering, the component tree is created and the lifecycle jumps to the Render Response phase.

·         Apply Request Values: Each component in the tree extracts new values from the request parameters and stores the values locally. If a component has its immediate attribute set to true, then the validation, the conversion, and the events associated with the component are processed during this phase.

·         Process Validations: It is one of the most important phases of JSF life cycle. The process validation is done through the following steps:

§  Conversion: The local values of components are converted from the input type to the underlying data type.

§  Required Check: If there are no failures in conversion, the required attribute on the component is checked. If the value is true then it goes for validation.

§  Validation: If the required check condition is true, and the associated field contains a value, then any associated validators are run. If the value is true and there is no field value, this phase completes (all remaining validators are executed), but the lifecycle jumps to the Render Response phase.

Condition checking in Validation Process Phase

·         Update Model Values: The component’s validated local values are moved to the model, and the local copies are discarded.

·         Invoke Application: Application-level logic (such as event handlers) is executed

·         Render Response: The components in the tree are rendered. State information is saved for subsequent requests and for the Restore View phase.