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:
FrameDeptViewEmpView1 extends JClientFrame
(a dummy implementation of the JClientPanel interface)
MDPanelDeptViewEmpView1 extends JPanel and
implements JClientPanel
PanelDeptView extends JPanel and implements
JClientPanel
PanelEmpView1 extends JPanel and implements
JClientPanel
where JPanel is a Swing class, and JClientFrame
and JClientPanel are part of JClient and constitute your
application&rsquos data browsing 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.
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:
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.
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.
MDPanelDeptViewEmpView1,
in the example above) and sets the panel binding on the new layout
panel, using the setBindingContext() methodd.
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).
Copyright © 1997, 2004, Oracle. All rights reserved.