JClass DataSource

1

Using JClass DataSource
The Two Ways of Managing Data Binding in JClass DataSource
Using JClass DataSource with Visual Components
JClass DataSource and the JClass Data Bound Components Internationalization

1.1 The Two Ways of Managing Data Binding in JClass DataSource

The core of JClass DataSource is its ability to manage hierarchical data through its data model. The data binding mechanism is built on top of the data model. It contains convenience classes that can be used to do single-level binding of objects such as a text field to a particular column in a database table. This organization makes it easy for you to bind display components built with JClass Chart, JClass LiveTable, and JClass Field, and other similar components, to a particular database field without having to pay attention to JClass DataSource's mechanism for handling hierarchical data structures.
This simplified approach to data binding begins with the ReadOnlyBindingModel interface. It provides a single-level, two-dimensional view of a data set. It groups all non-update methods and handles read-only events. This interface exists only to provide a logical separation between read-only and non-read-only methods and event handling. It is extended to an interface named BindingModel, which extends ReadOnlyBindingModel and provides update methods. Operations can be performed on the row currently in focus (for example, by using getCurrentRowStatus()), or by specifying a row index (for example, getRowStatus(rowIndex)).
Abstract class ReadOnlyBinding extends BindingModel and provides a base for concrete subclasses. Public class Binding extends ReadOnlyBinding and provides update methods. Operations can be performed on the row currently in focus. Public class JDBCBinding is used to bind to JDBC databases.
Thus, programmers who need to bind a non-grid component to a database need to understand Binding and its related classes and interfaces. They need not delve into the intricacies of the DataModel and MetaDataModel interfaces.
For comparison, there are two ways of accomplishing data binding:
Using the Data Model:
DataModel dm = new TreeData();
MetaDataModel mdm = newMetaDataModel(dm, "select * from orders", c)
table.setDataBinding(dm, mdm, column);
Using Binding:
DataModel dm = new TreeData();
MetaDataModel mdm = newMetaDataModel(dm, "select * from orders", c)
table.setDataBinding(mdm.getBinding);

1.2 Using JClass DataSource with Visual Components

You can use JClass DataSource with other JClass products and with IDEs that supply data bound visual components. Naturally, the recommended GUI is JClass HiGrid, a versatile and customizable grid built specifically to work side by side with JClass DataSource. You can use JClass LiveTable to bind different tables to a hierarchically-structured data source that you have designed and then built using this product, or you can connect the data bound components of JClass Field and have a form that displays database records wherein the end-user may make edits. Because JClass Field validates its input based on your specifications, your application is even more functional without you doing all the programming that implementing validation makes necessary. You can use JClass Chart to present values extracted from a database in a visually appealing way, again with customizable features so your application has your own personal flavor.
If you want to use an IDE's visual component, you can still simplify the job of connecting to the database and organizing its tables to meet your application's individual needs.

1.3 JClass DataSource and the JClass Data Bound Components

JClass DataSource is designed to be used for general-purpose data binding needs. In an IDE, all that is required to supply your form with data bound components is to place a JClass JCData or JClass JCTreeData and use their customizers to configure their properties, which include connecting to a database and, in the case of JClass JCTreeData, defining the master-detail relationships between parent and dependent data tables.
JClass components are data-aware. You use their customizers to register with the data source defined with the aid of JClass JCData or JClass JCTreeData. Custom property editors turn this operation into a sequence of choices - no writing of code is required.
The following chapters discuss the use of JClass DataSource and the data bound components in detail.

1.4 Internationalization

Internationalization is the process of making software that is ready for adaptation to various languages and regions without engineering changes. JClass products have been internationalized.

Localization is the process of making internationalized software run appropriately in a particular environment. All Strings used by JClass that need to be localized (that is, Strings that will be seen by a typical user) have been internationalized and are ready for localization. Thus, while localization stubs are in place for JClass, this step must be implemented by the developer of the localized software. These Strings are in resource bundles in every package that requires them. Therefore, the developer of the localized software who has purchased source code should augment all .java files within the /resources/ directory with the .java file specific for the relevant region; for example, for France, LocaleInfo.java becomes LocaleInfo_fr.java, and needs to contain the translated French versions of the Strings in the source LocaleInfo.java file. (Usually the file is called LocaleInfo.java, but can also have another name, such as LocaleBeanInfo.java or BeanLocaleInfo.java.)
Essentially, developers of the localized software create their own resource bundles for their own locale. Developers should check every package for a /resources/ directory; if one is found, then the .java files in it will need to be localized.
For more information on internationalization, go to: http://java.sun.com/j2se/1.4.2/docs/guide/intl/index.html.