PB & Java

Digg This!

One of the greatest selling points of the PowerJ development environment is its ability to use DataWindows. The same DataWindow that's created in PowerBuilder, and a major contributor to the success of that environment, is available to the Java programmer who uses PowerJ.

How useful are DataWindows in the Java environment? What are their strengths and weaknesses? Other avenues are available to the Java programmer using PowerJ - you can use bound controls or even pure JDBC, which handles all database access and data display in code.

This article will explore the pros and cons of all three approaches and attempt to devise a formula for selecting one for any given project. To make such an analysis we'll start with a quick overview of each approach and how it's handled in the PowerJ environment.

Using DataWindows
Any developer who has used PowerBuilder will be very familiar with the use of DataWindows. Successful PowerBuilder development is almost always centered around their use. Sybase has given the DataWindow to Java developers through their development of the Java DataWindow control.

The Java DataWindow control is a pure Java control that allows you to use standard DataWindow objects in your Java applications. These DataWindow objects are the same as the ones used in PowerBuilder and can be created either in PowerBuilder or by using the new DataWindow Builder tool that ships with PowerJ.

The DataWindow Builder is simply PowerBuilder's DataWindow and database painters stripped out into their own application (see Figure 1). It's used in the same manner as the PowerBuilder DataWindow Painter - you simply create any valid SQL statement, either using the point-and-click interface or by writing the SQL manually, then use the painter to position the result set columns as desired. When finished, you save the DataWindow object into a PowerBuilder Library file (PBL).

To use the DataWindow object in a PowerJ application, you must place it within one of the Java DataWindow controls provided for that purpose. These controls encapsulate all the code necessary for the DataWindow to be displayed in your application at runtime, and they expose the methods you'll call to interact with the DataWindow and its data.

To connect to the database place a PowerJ Transaction component on your form, connect it to the database and bind it to the DataWindow control. All this can be done at design time, with no coding involved. Once this is set up, the code that makes the DataWindow display data is simple: Datawindowcontrolname.retrieve(); The DataWindow control also exposes methods that allow you to interact with the data displayed and update the database with the changes, or to automatically perform data validation when the user enters or alters the displayed data. PowerBuilder developers will be very familiar with this functionality so it need not be discussed here.

Using Bound Controls
The AWT and Swing components on the PowerJ toolbar can act as bound controls, meaning they can be bound to a database column (or columns) via a PowerJ Transaction component and a PowerJ Query component. Developers who have used Visual Basic or Delphi will be much more familiar than PowerBuilder programmers with the concept of bound controls.

Here's how bound controls work: begin by placing a PowerJ Transaction component on your form and setting its properties to connect to the database, using the appropriate JDBC driver for your database.

Place a Query component on the form and set its properties to retrieve the data you want to display. To do this, set the connection property of the query to use the Transaction component you just placed on the form.

Set the query property of the component to any valid SQL statement to retrieve the desired data (see Figure 2).

Either enter the SQL statement in here as a text string or use the SQL Statement Editor window (displayed by clicking Edit) to paint the statement graphically, as shown in Figure 3.

Once you have a Transaction component and a Query component set up, place the components on the form and bind them to the database column that they'll be displaying. This is done entirely at design time using the database tab of the component's property sheet. Figure 4 shows the property sheet for an AWT text field, binding it to the first_name column of the query.

When the application is run, the data will be displayed in the bound controls. PowerJ also provides a Data Navigator component that allows you to easily move through a result set without writing code, using VCR-like controls.

The bound controls don't offer the developer any of the built-in methods of the Java DataWindow control, which can be used to interact with the data or perform data validation. All of this must be hand-coded (for example, to ensure that the user enters a valid date into a date field), although some of it can be done at design time using the masked text field provided by PowerJ. Still, the DataWindow far outshines the bound controls in this area.

Using "Pure" JDBC
In the pure JDBC approach, the developer must handle all database interaction in Java code. The developer is responsible for writing the code that sets up the JDBC driver, connects to the database, executes the SQL and then walks through the result set to extract the data. This data is then displayed in controls on the form using the normal setText() or another method to interact with the control at runtime. The following code demonstrates how to display the results of a simple query in a text field using nothing but Sun-supplied Java classes.

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection con = DriverManager.getConnection("jdbc:odbc:easdemodb", "dba", "sql");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT first_name, last_name, phone FROM contacts");
String fname = rs.getSring("first_name");
// set the name into the field, repeated for every field in the result set
textf_fname.setText(fname);

This approach is appealing to developers who are familiar with Java and want to avoid using any code or components in their application that are not provided by Sun.

Which to Use
Deciding which of these approaches to use is a matter of balancing the needs and capabilities of the developer against such things as speed of development, performance, and avoidance of proprietary code and components. Several factors must be considered.

If your application developers have PowerBuilder experience or you're porting an exisiting PowerBuilder application, take a close look at the DataWindow approach. By using DataWindows it may be possible to dramatically cut development time. This is because the DataWindow object itself makes up the majority of the user interface, and much of the code that manipulates the DataWindow and its data is directly translatable from PowerBuilder to Java. For example, the line:

Datawindowname.retrieve()

is the same in Java as it is in PowerBuilder and can simply be cut and pasted from the PowerBuilder app into the Java app. However, pay attention to any case problems that might arise due to Java's case sensitivity. If you make sure you name the controls in the Java application the same as the ones in the PowerBuilder application, you can use a lot of the PowerBuilder code from the previous application.

There are trade-offs, however. One of the most serious is the increased size of your application. The Java DataWindow control and its supporting classes are quite large. If your application is a Java applet, or is otherwise downloadable across low bandwidth connections, the size of these classes mandates against the use of DataWindows.

Another trade-off is that the Java DataWindow control is proprietary to Sybase. Many Java developers prefer to use only controls and components native to Sun's implementation of Java or that they develop themselves. If you belong to this camp, you certainly won't use DataWindows. Likewise, if you want to stick to pure Sun-provided Java, you wouldn't use the bound controls approach since the Transaction and Query components are also Sybase provided. If you want to stay only with Sun-provided Java, you're limited to using only the pure JDBC approach.

But what about the middle-of-the-road approach - using bound controls? In a low bandwidth situation in which you don't mind using proprietary Sybase code, this approach can save you substantial development time over the hard-coded, pure JDBC approach.

So which should you use? I generally advise clients as follows.

Use DataWindows if you are:

• Converting an existing PowerBuilder application
• Or have developers who are familiar with their use
• And are writing a Java application, not an applet, where bandwidth is not an issue
• And development time is an issue

Use bound controls if:

• You're writing a Java applet
• Or you don't have any developers familiar with DataWindows and there's no time to learn how to use them

Use pure JDBC if:

• You want to avoid non-Sun Java code at all costs
• And development time is not an issue

If you balance all these factors, you'll determine that all three approaches have their uses. The key is not to be so bound to one approach that you can't see the good points of the other two. Doing such automatic elimination can lead you to increased development costs and times.