All Things New

Digg This!

Now that Steve has discussed frameworks and building from scratch, I'll cover some things to help you avoid writing duplicate code.

Remember that the purpose of these articles is not a tutorial with step-by-step instructions but a guide to assist in the design and development process. Our goal is to help new developers get started in the right direction and to avoid pitfalls. This month's column will center on pitfalls with the Web target.

Before I discuss Web targets I want to reemphasize the foundation that Steve covered last month. A solid foundation and base classes are extremely important to an object-oriented development effort. A very simple example of a base class that is a pitfall is the MessageBox functionality. The MessageBox function is used to display information and errors to users and to ask questions. This function is used hundreds of times in any application and possibly even more. I had a relatively small application at a new client last year that contained 263 MessageBox function calls. The client wanted to customize the look of the message window and add an additional button for help.

Unfortunately the original developer didn't use any object-oriented practices. I had to replace 263 MessageBox functions with a standard approach. The approach I took was to implement my framework for all the client's applications. One of the framework's base class objects is a function to display a message. This function originally used a MessageBox when it was called but was easily modified to use a new Response window customized to the client's needs. Yes, the original implementation of the framework took some time and maintenance coding, but it made it all worthwhile. The next time they want to make a change to the messages presented to the user, it will be changed in one place only! I believe this is a pitfall to be avoided.

DataWindows
One of the most important objects in any PowerBuilder application is the DataWindow. Sybase extended this functionality in version 7 with the creation of the Web DataWindow. As the name implies, the Web DataWindow takes a DataWindow object and data and dynamically creates a page of HTML and JavaScript to be displayed in a browser. Why is this functionality so important? It allows us to use the same object to display and update information in a client/server and a Web application. We don't need to have different objects for each type of application. We will be using the same DataWindow object in both of our applications.

You may ask why am I talking about Web DataWindows but not writing any code? The answer is that one of the pitfalls that occur when creating your first Web application is coding the connection to EAServer in each page. The pages may work fine and the application runs well on your laptop or test server; however, what happens when you move into production? You need to go and change all the places that reference the server. Remember the MessageBox example? Same thing.

The Web DataWindow is not magic. It's a PowerBuilder nonvisual object (NVO) that is deployed to EAServer as a CORBA component. Once it exists in EAServer, it can be executed by anything that can communicate with CORBA, such as Java or JSP. There are five steps in a simple Web DataWindow page. Listing 1 shows the JSP code.

1. Create an instance of the component.
2. Set the PBL and dataobject.
3. Set the transaction object.
4. Retrieve the data.
5. Generate the HTML.

JSP Target
What we are planning is to develop two applications that have the same functionality. One is written as a client/server application and the other a Web application. The Web application is a JSP target that we started in my last article. The purpose of a JSP (JavaServer Page) page is to generate dynamic content, typically from a database query. As an example, think about ordering software products from Sybase.com. There are many different pages that are used when placing an order: searching for products, displaying the specifications and pictures of a product, placing products into a shopping cart, and then going through the checkout and payment process. Many of these pages may use the same logic to display information, so I will concentrate on how to avoid duplicating code.

The section of the code that I'll review creates an instance of a PowerBuilder component named HTMLGenerator100. This is a sample component that Sybase provides to demonstrate how to write a PowerBuilder component that creates a Web DataWindow. Take a look at the line of code that begins with "Manager manager = ". Notice at the end of the line that the server name is specified, localhost in this instance. Also notice the next line, which specifies the username (jagadmin) and password (empty). Any page written in this manner has all critical settings hard-coded.

As you can see this is a pitfall to be avoided. All that is necessary to avoid it is to know a technique to store settings. The technique to be used is called include files. While this is not the only technique available, it is a proven technique. An include file is Java code that is placed within a file and can be added to a page. I prefer to name these files with an extension of .inc. A file named EAServerManager.inc is created with a text editor and contains the following lines:

<%
String s_machine = "iiop://localhost:9000";
%>

The first and last lines are identifiers to indicate that Java code is between the pair. The second line defines a String variable named s_machine and sets it to the server name to access. This is the one file that needs to be changed when deploying the application to a different server. Simple, right? The other change is to use this include file in the JSP. The following line is added to the JSP to use the include file:

<%@ include file="EAServerManager.inc" %>

The final change is to remove the hard-coded value in the page and replace it with the s_machine variable as shown below. Listing 2 shows the new page.

Manager manager = ManagerHelper.narrow(orb.string_to_object(s_machine));

Result
Naturally this was a very simple example of how to avoid a common pitfall. I also didn't put the other hard-coded values into the include file. Think of this as a sample exercise. Remember that design is important before coding begins. My recommendation is to try and think of as many of these potential pitfalls as possible before you start coding. On a final note, remember that there is often more than one way to accomplish the same task. The method demonstrated has been working for years but I'm certain there are other methods that are used each and every day. In the next article we'll finally start writing some code - promise.