Back in 1997, I was working on Riverston's HOW UML CASE tool, which was able to generate a full PowerBuilder application from adapted UML diagrams.

This tool doesn't exist any more, but it showed us that there were other ways to explore application development with modeling, UML technology, and PowerBuilder. It just seemed to me that Sybase was missing something else in order to adapt PowerBuilder for Web application development.

Back then, Web application development was largely limited to static pages on Web sites; Microsoft had only just introduced the first version of their ASP technology. We were all building client/server applications with PowerBuilder 5 and productivity was still our main target when building or maintaining applications.

I had an idea for creating a new application modeling technology based on what most PowerBuilder developers had been doing for the prior six years: put the "window" concept in the center of the designing methodology. You start by referencing all the windows needed by your application, and then describing all the features that will be covered by each window and how your windows should be linked, one with the other. You don't need to be a genius to invent such a methodology. In fact, many PowerBuilder developers (and legacy systems developers) had been using a similar "homemade" approach for many years and they had obviously reached a high level of productivity with it. The only problem was how to adapt that way of thinking - one that works well for mainframe or client/server application development - to Web application development.

What I came up with was the "proxy window" concept. This concept separates the graphical representation of a window from its logic. This is quite different from what you may have heard a million times about separating the business logic from GUI logic (which we have been doing for some time with client/server application development by using stored procedures and then later NVOs running on component servers). A "proxy window" would be an NVO that would include all the application logic included in a window object. It would run on a server and generate all the needed HTML code to display the corresponding "Web window" into a Web browser. Then the "Web window" would communicate with the NVO depending on events triggered by the end user.

The graphical representation of a Web window would fit into the targeted graphical environment. That is, the Web application would look like a Web application in the Web browser, not like a Microsoft Windows-based GUI client/server application. When I started creating those NVOs with PowerBuilder and exporting the source code, I noticed they looked pretty much the same as my client/server application window objects. They just didn't inherit from the PowerBuilder window class but from the PowerBuilder user object class

Although both objects' source code looked pretty much the same, it was much more difficult and it took me a lot more time to design and develop the NVO than the graphical window, using PowerBuilder. I decided to try moving my PowerBuilder window into a Web "proxy" window (see Table 1 for a comparison).

First I rewrote all PowerBuilder graphical classes as NVOs (see Figure 1), then I exported the source code of my windows and changed the ancestor classes of all graphical objects. Next, I imported the source code into a new PBL. I added a new "HTML" method to all my "proxy" classes. These methods return the HTML code needed to display the object in a Web browser. I deployed those components onto my application server (which was a distributed PowerBuilder application in 1997). I accessed my object from a Web browser (using the web.PB technology in 1997). It was working!

I decided to create a tool that would let me create my Web applications from the Windows GUI applications that are so easy and that take so little time to develop with PowerBuilder. The client/server application would be used to describe the application logic, then I would describe the graphical representation of the application with the tool, and it would also generate all those "proxy windows" for me. HTMLBridge was born.

Developing a Web Application with HTMLBridge
There are four basic steps involved in developing and deploying a Web application using HTMLBridge. First, describe your application logic by building a classic client/server application with PowerBuilder. Next, define how it should look in a Web browser with HTMLBridge's theme painter and webzard Painter. Then have HTMLBridge generate nonvisual components that include all your application logic and which, in turn, generate the needed HTML code for your application GUI. Finally, deploy the generated components on your target Web HTTP server and your target application server. You can now access your application from any Web browser.

Supported GUI Features
My target was to support the main PowerBuilder GUI features so that the users of my applications could keep the same level of productivity they had with my Windows client/server GUI ones. Many people say that Web HTML applications don't offer a GUI as rich as client/server. This is true when using scripting technologies, but I was using PowerBuilder, which includes an object-oriented development language and the HTML DataWindow technology. I should be able to implement a rich GUI feature even if it would not be as good as client/server ones (or it would cost too many lines of JavaScript code to try to simulate them). All I had to do was translate my Windows GUI features into Web/HTML GUI features in a Web state-of-the-art way.

I think it is very important that a Web application looks like a Web application. First, because Web application users won't get lost when using it. Second, because what made Web technology popular is that it is nice looking. You can't imagine using a Web application with a grey background and no pictures (see Figure 2). I needed to keep the logic but change the representation. For example: menu objects are used for navigating from one application process to another. This is the application logic part. In a Windows GUI application, the graphical representation of this menu would be at the top an MDI frame window, and subitems would display within a pop menu. In a Web GUI application, this menu would be a list of hyperlink text in the left part of the Web browser (see Figure 3).

One of the most difficult features was that I didn't want my entire Web browser display area to get refreshed when communicating with the application server. This would have turned my Web application into a fat network application by reloading all HTML source code each time the user triggered an event. I only wanted to refresh the needed part of the screen depending on the user's actions. By using HTML frames, I could refresh only one frame and not the whole screen and even avoid refreshing when not needed.

Built-in Supported GUI Features

• Menu navigation (hyperlinks or treeview hyperlinks)
• Tabular input (DataWindows), tabs, and custom HTML code
• Freeform input, data sharing , itemchanged server event
• QBE input, DropDown DataWindows , tabular display
• Treeviews and listview
• Master/detail windows (refreshing only the retrieved DataWindow)
• Secured PDF reporting