| Class | Description |
|---|---|
| UIMessageBundle | |
| UIMessageBundle_en |
This package contains client-side message bundle classes that are used in JClient for generating translatable messages.
About JClient Application Code
In a JClient application, data binding between the Swing controls and Business Components datasources 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 JFrame
LYPanelDeptViewEmpView1 extends JPanel
PanelDeptView extends JPanel
PanelEmpView1 extends JPanel
Where JFrame and JPanel are Swing classes. When you run the application, starting with the JFrame, the following JClient code is executed:
main() bootstraps the application
by creating an application object (JUApplication) that allows an application module
session object to be created.
jbInit() method,
the data browsing (children) panels are
created. For this, JClient passes the layout panel's panel binding into the
children data panels (PanelDeptView and PanelEmpView1 in the above example). Thus,
children panels share the panel binding with the layout panel.
During design-time, each data browsing panel you add to the JClient application gets it context for marshaling interactions between the UI controls and the Business Component datasource's rowset iterator from the panel binding created in the frame or layout panel. Once you have a frame or layout panel that creates this panel binding, JClient permits you to assemble the application by adding new data browsing panels.
Then you can use the UI Editor in JDeveloper to add controls one by one to
the data panel. You set 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 data bound through a getPanelBinding() call
as an argument to its setModel() or setDocument()
method.
About the Frame or Applet Class in JClient
Application Bootstrap
When you run the JClient application by selecting the Frame or Applet class in the Navigator and select Run, one of the first things that happens in the JClient bootstrap code is the creation of the JUApplication object. The following code line makes this happen:
JUApplication app = JUMetaObjectManager.createApplicationObject("MyJClientProject.ClientDataModel1",
null, new JUEnvInfoProvider());
The first parameter to createApplicationObject(), "MyJClientProject.ClientDataModel1",
identifies the data model from which the JUApplication instance is to be created.
A JUMetaObjectManager object takes this name and uses the first part (MyJClientProject)
to form the client project file name (MyJClientProject.cpx). The
.cpx file is read and parsed. The Session information is extracted
and cached in JUMetaObjectManager.
Then, the Session definition, specifically the Package
and Configuration values, is extracted. The information is passed
to the ApplicationModule pool manager, which creates an application module instance.
(Refer to the Business Components for Java documentation for information about
the ApplicationModule pool.)
The JUApplication instance is created from this application module instance.
Frame Initialization
After the JUApplication is instantiated, initialization of the frame proceeds.
An instance of the frame is created by invoking the constructor that takes the
JUApplication. That constructor creates the status bar for the frame and saves
the JUApplication reference in a field (app). Then, it calls jbInit()
and initialization of the main layout panel proceeds.
Applet Initialization
After an instance of the applet is created, initialization of the applet proceeds.
The JUApplication is created and the reference is saved in a field (app).
Then jbInit() is called and initialization of the main layout panel
and the status bar proceeds.
About the Layout Panel in JClient
The main panel within a JClient frame is called the layout panel (field "layoutPanel"). This panel is a UI container for one or more data browsing panels. If the frame is to show master-detail data, the layout panel will contain two data browsing panels, one for the master and one for the detail.
The layout panel is created through a call to the contructor that takes the JUApplication. An important part of layout panel initialization is the creation of the panel binding. Panel binding acts as the container of all "iterator bindings" used by the panel (or its children). An iterator binding is the object that marshals interactions between UI controls and BC4J datasource rowset iterator.
The panel binding is registered with the application (JUApplication) object through the following line of code:
panelBinding.setApplication(app);
In the layout panel's jbInit() method, the creation of the data
browsing (children) panels proceeds. For this, JClient passes the layout panel's
panel binding into the children panels. Thus, children panels end up sharing
the panel binding with the layout panel.
About Data Panels in JClient
A data browsing panel contains controls through which the user can view and
edit data. Thus, it has a set of controls declared and instantiated as fields.
The data browsing panel receives its panel binding from the layout panel (in
its constructor). After that, jbInit() is called.
In the jbInit() method, binding of the control to attributes occurs.
Examine the following code:
textFieldDeptName.setDocument(JUTextFieldBinding.createAttributeBinding(getPanelBinding(),
textFieldDeptName, "DeptView", null, "DeptViewIter", "DName"));
The above code line sets the Swing Document object for a text field named textFieldDeptName.
In short, textFieldDeptName is to show and edit the DName
attribute of the view object named DeptView.
The Document object is created by a static createAttributeBinding()
method on JUTextFieldBinding. JClient provides model objects for
Swing controls (where the model for text field is called Document) that are
responsible for marshalling interaction between the Swing controls and BC4J
rowset iterator. We refer to these JClient implementation of Swing models as
control bindings.
The first parameter to createAttributeBinding() is the panel binding.
The second parameter is the text field control itself. The third parameter DeptView
identifies the view object. In order to locate the view object, we need the
application module in addition to the view object name. The application module
is provided by the panel binding (the first parameter) since the panel binding
is registered with the JUApplication object. While this happens, the panel binding
receives the application module reference from the JUApplication object. This
application module is used as the context in which the named view object is
found.
The fourth parameter is an optional name of the rowset iterator within the view object. This enables the user to work with a secondary rowset iterator if desired. To use a secondary rowset iterator, the user must change code manually and enter the name of the rowset iterator. "null" means that this control will bind to the default rowset iterator of the view object.
The panel binding keeps a list of iterator bindings. Each iterator binding
specifies the view object instance and (optionally) the rowset iterator. An
iterator binding (within the panel binding) is identified by its name. The fifth
parameter (DeptViewIter) specifies the iterator binding name.
Thus, when createAttributeBinding() is called, JClient tries to
look for an iterator binding by the specified name (DeptViewIter).
If one is found, JClient uses that iterator binding. If one is not found, JClient
uses the view object name and rowset iterator name to create a new iterator
binding, assign its name, and register it with the panel binding.
The last parameter (DName) is the name of the view object attribute
to which the text field is bound.
About Control Binding in JClient
Populating Controls with Data
After data browsing panels are initialized, the layout panel calls executeIfNeeded()
on the panel binding to execute the query on the BC4J datasource.
This method checks to see if the query had been executed on the view object
and if not calls executeQuery() on it. This brings data from the
database into the cache and causes BC4J's RowSetListener events to fire. The
first among these would be the RowSetListener.rangeRefreshed event.
This event is captured by the iterator binding (because it implements RowSetListener
and has registered itself as a listener). It retrieves the rows of the range
and calls updateValuesFromRows() on the control binding. The control
binding takes the data out from the rows and assigns them to the controls using
Swing API. This updates the panel UI with the data.
Updating Data through Controls
The user's interaction with a JClient-bound control may result in updating
of data through BC4J APIs. Let's take textFieldDname (TextField) for an example.
If the user edits its content and leaves the control (generating focusLost
event), JClient is notified of the event. It retrieve the updated data from
the control and calls setAttribute() on the row.