As with any application, I like to address the database needs first before writing any non-prototype code. Since the database was designed with one company in mind for our client/server products, we needed to create a company table and add the new company_id column to most of the other tables (see Figure 2). In addition, my PB 11 hosting company did not have SQL Anywhere available so I had to convert the tables to SQL Server 2000. (I would have gladly used SQL Anywhere if it were available.) This conversion is relatively easy and I only needed to redefine the SQL Anywhere timestamp columns to SQL Server 2000 datetime columns. (SQL Server timestamps are actually binary and not used for dates and times.)

Once the SQL Server database was ready, I was all set to look at the presentation and business layers.

I was ready to migrate the application to Web Forms. Once it was migrated I noticed that some PFC ancestor events caused postbacks. I realized that if speed was my goal (and it should be yours also), we needed a new foundation library so unnecessary trips to the server were eliminated. Therefore I created a new native PB ancestor window and business class. My next step was to develop new resizing functionality and replace the DataWindow of_setsort() functionality that I had with the PFC. The resizing logic was easy but the equivalent sorting code in native PB would have been placed in the clicked event and that would cause a postback (so this function was abandoned).

With the foundation library complete, I was ready to reuse the most complex part of the 10.5 application: the business and data layers. I migrated all the DataWindows but needed to add the new company_id column to each of them and to add a new :an_company_id retrieval argument. I also went though each result set and removed any columns that were not required. (I reasoned that although returning entire result sets in the client/server world was fine when you are building reusable classes, we want to conserve resources to achieve the fastest rendering possible in the browser.)

I was ready to address the interface. Since I was using a tabbed interface in my original design, I made a decision to create a window for each of the tab pages. My reasoning behind this is that users may or may not use all tab pages, so the weight of loading any unnecessary code did not make sense. Now each new Web window has a hyperlink to other windows as opposed to the client/server app, which uses a menu and toolbar (see Figure 3).

The next step was the longest process: to leave my client/server skills behind and design a new Web interface. Each tab page in the client/server app has a DataWindow treeview, a main DataWindow, and NEW, SAVE, DELETE and PRINT command buttons. In my first cut of the new Web Forms application (see Figure 4) I had replaced the DataWindow treeviews with native treeviews for performance reasons (the DataWindow control generates more code). Then I had an epiphany: To maximize speed, I reasoned that having treeviews to display data that a user might not need was overkill. So I replaced it with "Find" functionality so the user finds and uses only the data they need (see Figure 5).

With the interface having a new Web look and feel, I was ready to reuse the business logic. Since the itemchanged logic can cause postbacks (unless you implement JavaScript callbacks), I put most of the validation logic in NVOs and called them from each of the windows ue_save events (see Listing 3). I determined that there are two types of messages: informational statements and questions/server errors. I removed as many messageboxes as possible. To notify the user that something had happened, I added a computed text field on each DataWindow to display messages (see Figure 6). (Messageboxes cause a trip to the server when the user clicks their buttons.)

Now that the windows were functioning, the last step was to re-engineer the PBNI SMTP and TAPI OLE functionality with .NET SMTP (with attachments [see Listing 4]) and the Callfire Web Service, respectively (see Listing 5). There are several VoIP Web services available. The .NET SMTP examples can be found in the Sybase newsgroups (search .NET and SMTP). Sybase has a Web Service example that will get you started.

Conclusion
PB 11 works as advertised and is an excellent toolset to get Web apps up and running fast. It did not take too long to rebuild our existing application because I was basically working with the same toolset I've been using for several years. I was also able to reuse the most complex pieces of the original application: the business and data layers!

Our new Web-based application: works great and new customers are coming on board from all over the world. My recommendation is that if you are converting an existing application to be Web-based, check out the differences between Windows Forms and Web Forms applications. After you determine which one will work best for you, take a good look at your foundation classes. Build new classes if you have to and reuse your business logic and DataWindows. The biggest obstacle for me was to think "Web" and not "client/server." I have learned that although I have created static Web sites before, creating a data-driven Web site was a definite paradigm shift. Personally, I am satisfied the technology works well and we will be converting our other applications to Web Forms in the near future.