About the Generated JClient Code

In an ADF JClient application, data binding between the Swing controls and the business services' data sources relies on the creation a set of JClient objects that closely resemble the UI containers used to assemble the JClient forms. You can see these containers and their JClient-specific code when you use the JClient Form wizard to generate a complete application. For example, assuming a master-detail type form, based on a Dept and Emp view object, the wizard would generate the following classes:

where JPanel is a Swing class, and JClientFrame and JClientPanel are part of JClient and constitute your application&rsquos data browsing panels.

How JClient Preserves the Data Context Between Data Panels

The JClientPanel interface implemented by JClientFrame or JPanel permits your JClient application to:

During design time, each data browsing panel you add to the JClient application gets its context for marshaling interactions between the UI controls and the business service&rsquos row set iterator from the panel binding object created in the frame or containing panel (such as the master-detail layout panel). The capability in JClient to chain data browsing panels is provided without the need to write additional code. For example, the data browsing panels generated by the wizard, PanelDeptView and PanelEmpView1, share the same data context through an instance of a panel binding (JUPanelBinding ) when each JPanel implements the setPanelBinding() and getPanelBinding() methods of the JClientPanel interface.

Once you have a frame or panel that creates this panel binding, JClient permits you to assemble the application by adding new data browsing panels that either share the existing panel binding object or create a new one.

Then you can use the Data Control Palette in JDeveloper to add databound controls one by one to the data panel. At the level of the Swing component, this sets the data binding by specifying a JClient control model on the control's document or model property. At runtime, each control in the data panel becomes databound through the the panel binding object as an argument to the control's setModel() or setDocument() method.

Process for Creating and Using the Panel Binding

To understand how the panel binding is created and used by the databound panels, consider what happens when you run the application, starting with the JClient frame, and the following JClient code is executed:

  1. The main() method bootstraps the application. It starts a binding context and loads the Oracle ADF data control, based on entries in the DataBindings.cpx file. Then it passes the binding context with initialized Oracle ADF model objects to the panel binding to create the Oracle ADF data bindings.
  2. The frame is initialized ( FrameDeptViewEmpView1, in the example above) through a constructor that takes an application object. Initialization of the frame results in a panel binding object (JUPanelBinding), based on an Oracle ADF model definition that may have components that are bound to data from more than one data control. The creation of the panel binding is an important part of the JClient functionality, which enables data binding for Swing components and chaining of data panels.
  3. The frame or applet class initializes a layout panel (MDPanelDeptViewEmpView1, in the example above) and sets the panel binding on the new layout panel, using the setBindingContext() methodd.
  4. In the layout panel's jbInit() method, the data browsing (children) panels are created. For this, JClient uses the shared binding context for binding the child data panels ( PanelDeptView and PanelEmpView1, in the example above).
  5. A control-to-attribute data binding occurs using the control's specified JClient model. (This binding information is stored in the binding container XML metadata.)
  6. The control binding handles events to populate and update data for the UI control.

 

 

Copyright © 1997, 2004, Oracle. All rights reserved.