| Managing ADF JClient Data Binding in a Multi-Form Application
An Oracle JDeveloper How To Document
This document assumes the following:
The runtime objects exposed by the Oracle ADF data binding API support the creation of multi-window applications wherein the end user interacts with a series of forms to complete a single task. For example, assume an order fulfillment application that displays a list of orders. In the multi-window application, the end-user would open a separate form to update the items in each order. In this scenario, data chaining needs to occur across two forms, and the end-user should be able to freely navigate the order list and view the current order's items in separate forms.
This document describes the runtime objects that support data chain in a multi-form JClient application. Utilizing these objects in a multi-form application requires some modification of the code generated by the JClient form wizards available in JDeveloper 10g. As a result of the code changes, you can display master and detail forms in separate windows and manage the end-user's interaction with these forms.
We will rely on these two use cases to depict the type of customization required to the JClient data binding code:
Before we analyze these use cases, you may want to review the following section to understand how JClient exposes the Oracle ADF data binding mechanism though its API.Data Binding Overview in JClient Forms
Data binding in JClient is the ability to create Swing containers and components that are bound to data in back-end business services. To enable data binding, JClient provides a small API that works with the Oracle ADF model layer. The API is exposed in the application source code through a combination of JClient bootstrap code:
To work with a data binding in your Swing application, each container (a frame or panel) must either create a panel binding object or get one from the source from which it originated. The frame that creates the first panel binding also contains the JClient bootstrap code, where the connection to the business services is created. Subsequent containers that your application creates either chain from the original panel binding or they create their panel binding in order to display unrelated data.
In the wizard-generated forms provided in JDeveloper, you can assume just one binding context and one panel binding object will be created for each databound frame or panel. In the following section we will see how to manage these objects to work with multiple forms.Data Binding in a Serial-Forms Use Case
In the serially opened forms use case, the end-user should be able to select an order, update an order, and continue with the application. Each form gets its panel binding object to enable access to the same set of business objects in the application's runtime binding context. The panel binding and the binding context together permit data chaining across the forms. However, unless a new panel binding is created for each new detail form (to update order items), the next form the end-user opens won't display the current selection (from the orders list). We want the separate forms to look like this, with the master order form on the left and the detail form, displaying order items, on the right:
To enable data chaining in the above multi-form application, where the end-user interacts with forms sequentially, the JClient application must support these tasks:
The application can implement these two tasks in the action listener of a button in each form. For example, when the end-user clicks the Open Order Items to Edit button in the master form, the action listener will determine whether a panel binding exists. Upon the first Open button click, no panel binding will exist and the action listener will initialize the binding container and create the panel binding that references the binding container for the detail form. Then, when the end-user clicks the Close button in the detail form, that button's listener will release the panel binding's business object references without disposing of the object for the current binding context. The end-user can return to the master form and open the next detail form, thereby "recycling" the original panel binding object with a new business object reference.
When the next detail form gets displayed, the component bindings in that form will create their own business object references and enable the form to display the detail information for the current master object selection. An added benefit of Oracle ADF data binding is that the ADF iterator bindings associated with each form manages synchronization of data between the forms and preserves master-detail navigation. In this case, when the end-user scrolls the list of orders, the order items form will reflect the change.Data Binding in a Concurrent-Forms Use Case
In this use case, the forms are the familiar master and detail, with the added ability to display multiple detail forms at the same time. We want the separate forms to look like this, with the master order form on the left and the multiple, detail order items forms on the right:
In the previous example, data binding each detail form was managed by recycling the panel binding object from the original binding container. This was possible when only a single form was open at a time. However, this strategy won't suffice if the end-user is to open and interact with multiple databound forms from the same master form. In this case, recycling the panel binding object would terminate the data binding of the previously opened form. Instead, to open multiple, independent forms that share the same data, the JClient the application must support these tasks:
This technique ensures that each detail form will have a unique panel binding and will therefore display the appropriate detail information. Specifically, we must modify the behavior of the action listener for the master form's Open Another Order to Edit button which will use an integer variable to create a unique binding container name before creating the panel binding object that ultimately will reference this uniquely named binding container for the detail form.
Furthermore, in this concurrent-forms scenario, it would be desirable to disable the navigation provided by the ADF iterator binding between the open detail and master forms. In other words, we want to isolate navigation so the end-user does not see all the open detail forms scroll together. Support for this task is provided by the Oracle ADF Business Components secondary rowset iterator (RSI), which lets you manage access to the master business object. Note that this requirement assumes the business service objects are implemented as Oracle ADF Business Components (as opposed to plain old JavaBeans or EJB components). Once the RSI object is created, the master form can set the iterator binding instance on its panel binding object.Creating the Multi-Form JClient Application
With the aid of JDeveloper 10g, let's create the above applications and implement the changes to the data binding code in the JClient wizard-generated forms.
Serial Forms Use Case
To lay out the master and detail forms:
To specify the custom data binding behavior for the button action listeners:
No other changes are required. In JDeveloper, compile the application and run
Concurrent Form Use Case
Create a new emtpy JClient project if you intend to use the same workspace. Lay out the master and detail forms by following the previously stated steps. You should have another set of
To specify the custom data binding behavior for the button action listeners in this use case:
No other changes are required. In JDeveloper, compile the application and run
How you want to manage the data views of in a multi-form application determines whether a container recycles a panel binding or gets a new one: