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.

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 the Fusion Page Cycle

ADF Faces page lifecycle extends the standard JSF request lifecycle, and the ADF page lifecycle.

The JSF life cycle has been explained in the following link.

The ADF page lifecycle handles preparing and updating the data model, validating the data at the model layer, and executing methods on the business layer. The ADF page lifecycle uses the binding container to make data available for easy referencing by the page during the current page request.

The combined JSF and ADF page lifecycle is only one sequence within a larger sequence of events that begins when an HTTP request arrives at the application server and continues until the page is returned to the client. This overall sequence of events can be called the web page lifecycle. It follows processing through the model, view, and controller layers as defined by the MVC architecture.

Diagram showing a web page life cycle with JSF life Cycle and ADF life cycle in tandem

How do JSF and ADF Phases integrate?

·         Restore View: The URL for the requested page is passed to the bindingContext object, which finds the page definition file that matches the URL. The component tree of the requested page is either newly built or restored.

·         JSF Restore View: Provides before and after phase events for the Restore View phase. You can create a listener and register it with the before or after event of this phase, and the application will behave as if the listener were registered with the Restore View phase. After the before and after listeners are executed, the page flow scope is available.

·         Initialize Context: The page definition file is used to create the bindingContainer object, which is the runtime representation of the page definition file for the requested page. The LifecycleContext class used to persist information throughout the ADF page lifecycle phases is instantiated and initialized with values for the associated request, binding container, and lifecycle.

·         Prepare Model: The ADF page lifecycle enters the Prepare Model phase by calling the BindingContainer.refresh(PREPARE_MODEL) method. During the Prepare Model phase, BindingContainer page parameters are prepared and then evaluated. If parameters for a task flow exist, they are passed into the flow. Next, any executables that have their refresh attribute set to prepareModel are refreshed based on the order of entry in the page definition file’s <executables> section and on the evaluation of their RefreshCondition properties (if present).

·         Apply Request Values: Each component in the tree extracts new values from the request parameters and stores those values locally. When immediate property on some component is set as true this phase behaves differently. Please read more on this link.

·         JSF Apply Request Values: Provides before and after phase events for the Apply Request Values phase. You can create a listener and register it with the before or after event of this phase, and the application will behave as if the listener were registered with the Apply Request Values phase.

·         Process Validations: Local Values of components are converted ad validated on client. At the end of this phase, new component values are set, any validation or conversion error messages and events are queued on FacesContext, and any value change events are delivered.

·         JSF Process Validations: Provides before and after phase events for the Process Validations phase.

·         Update Model Values: The component’s validated local values are moved to the model and the local copies are discarded. For any updateable components (such as an inputText component), corresponding iterators are refreshed, if the refresh condition is set to the default (deferred) and the refresh condition (if any) evaluates to true.

·         JSF Update Model Values: Provides before and after phase events for the Update Model Values Phase.

·         Validation Model Updates: The updated model is now validated against any validation routines set on the model

·         Invoke Application: Any action bindings for command components or events are invoked.

·         JSF Invoke Application: Provides before and after phase events for the Invoke Application Phase.

·         Metadata Commit: Changes to runtime metadata are committed. This phase stores any runtime changes made to the application using the Metadata Service (MDS).

·         Prepare Render: The binding container is refreshed to allow for any changes that may have occurred in the Apply Request Values or Validation phases. Any iterators that correspond to read-only components (such as an outputText component) are refreshed. Any dynamic regions are switched, if needed. Jdeveloper displays refresh(RENDER_MODEL) instead of prepareRender as a valid phase selection.

·         Render Response:  The components in the tree are rendered as the Java EE web container traverses the tags in the page. State information is saved for subsequent requests and the Restore View phase

·         JSF Render Response: Provides before and after phase events for the Render Response.

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.