| Downloads |
|---|
| 19900.zip |
Any time you upgrade or migrate a Web site or application, you should also review the site's code, tools, and architecture. The overhaul gives you an opportunity to improve the site or application's functionality, performance, and maintenance. At my consulting company, our developers got together recently to update the entire Web site, and although we undertook the project for business reasons, the upgrade gave us a chance to make technology changes as well. The changes included installing a new interface to make the site easier to navigate, refreshing the graphics, and adding new informational pages to reflect changes in our business. We upgraded technical parts of the site by taking such steps as changing the interface on data access pages and adding new query pages. Note that when we started to redesign our site, the first thing we did was to follow good backup practices by copying the entire site to a new Web development site. Then we worked on the copy. The original site saved the day a couple of times when we inadvertently overwrote code.
First, we looked at the Web site application code to decide what we should retain and replace. We also looked at code that we could move into Include files as script functions. We used Microsoft Visual InterDev to develop the site, so vestiges of early Visual InterDev-generated code remained. For example, many pages that accessed SQL Server retained code similar to the code that Listing 1 shows. The 11 lines of ADO access code in Listing 1 work well, but they repeat on page after page. We standardized our access in a library named database.asp. However, we hadn't examined the entire site and changed all the database access code to the new format. (If it isn't broken, don't fix it—right?) So, as the developers upgraded the site, they streamlined all data access by adding the following line for the Include file library:
<!--#INCLUDE FILE="../Scripts/ Database.asp"-->
Then, they replaced the 11 lines of code in Listing 1 with the line
set rsCourse = RunWithRS(curSQL)
Of course, every time we encountered the rsCourse variable, we changed it to the proper variable name for the current recordset. The curSQL variable contains the SQL statement. The RunWithRS() function from the Include file performs the ADO magic, as Web Listing 1 shows.
By making these simple code changes, we eliminated nine lines of code for every data access in the Active Server Pages (ASP) scripts. If an ASP file used more than one database access, we eliminated 10 lines of code for each additional database access. The benefits you gain by replacing code in this manner are twofold. First, when you reduce all database access to one set of routines, you can more easily update database access functionality. Second, the smaller volume of code reduces the pages' complexity and makes the pages easier to maintain. Because the database access code is hidden in functions, you don't have to be an ASP or ADO guru to work with it. Instead of replacing code, you can move the data access code to a middle-tier Visual Basic (VB) object. At my company, we don't take this approach because our Web site runs on a server at an ISP that doesn't support COM components.
After we brought our code up-to-date, we evaluated the tools available to us. Visual InterDev, which we had used almost exclusively since we set up our Web site, was our choice for all server-side scripting, database, and debugging work. To this point, we had also relied on Visual InterDev for our HTML and layout work. We decided to use Microsoft FrontPage 2000 for part of the project because of its ease of use with HTML and layout work in general, and because it works well with Visual InterDev. FrontPage 2000 performed much better with ASP script in pages than earlier FrontPage versions, which changed ASP script, thereby breaking applications. But during my testing, FrontPage 2000 didn't alter my script, as earlier versions did. For example, FrontPage 98 and earlier often changed characters such as & to special HTML character sequences. When ASP processed the page, the code wouldn't run.
Maintenance of any site or application is a costly undertaking. As part of our upgrade planning, we looked at features of ASP, Microsoft IIS, FrontPage, and Visual InterDev that would facilitate site maintenance. Let's review a couple of timesaving features we discovered in FrontPage 2000 as we redeveloped our site. FrontPage 2000 incorporates a site-management feature that lets you break up your site into several different subwebs that share common script libraries and images. (A subweb is another name for a virtual directory under the parent Web site.) You can turn the individual folders for the site's subsections into subwebs by right-clicking the folder and selecting Convert to Web. Next, click the Folders icon in the left menu bar to open the Folder list, then double-click the subweb name.
After you've divided your site into subwebs, you can implement FrontPage 2000's shared borders feature to consolidate the site's common parts. The shared borders feature lets you assign each subweb a designated border area that the subweb can share across multiple pages. For example, if you add a top shared border to a subweb, FrontPage 2000 copies the top border into each page's body section. This copy or insert process happens during design time, not runtime, so no Include file or extension problems can crop up when the site is running. To engage the shared border feature, go to the Folder List window, choose the Format Menu, then select Shared Borders. Clicking Shared Borders displays the Shared Borders dialog box that Web Figure 1 (available online) shows. Just select the borders you need, and click OK.
Using shared borders saved us many days of work on our site during our upgrade because they reduced the amount of HTML code we worked with and eliminated the use of an Include file for borders. We use Top, Left, and Bottom borders on each page of the site except the login pages. The Top border contains the standard page header and menus. The Left border contains a small spacer graphic to add white space. The Bottom border contains the copyright information for the site. A subweb stores the border files in the _borders folder. Because all the subweb borders are in the _borders folder, you need to manage only one set of borders for that subweb. You can copy shared borders between subwebs. For example, all our subwebs use the same Bottom and Left borders. When we had formatted these borders correctly, we copied them to each subweb's _borders folder. FrontPage 2000 detected the change and updated the pages.
The HTML that Listing 2 shows generates a sample shared border from our site. In the last table row, notice the ASP variable <%=spagetitle%>, which lets you display a standard title for each page. You can drive this variable from SQL Server by setting the variable before the <body> tag to a value that you retrieve from SQL Server by using ADO. When the page displays, SQL Server sets the variable.
So far, we've seen that code and tools are important elements to review when you maneuver your site through an upgrade or redesign. But don't forget the reader's browser. It's an important architectural consideration, so we researched the browsers our site visitors were using. When we learned that very few people had used Netscape to access our site in the previous year, we decided to rebuild the site for the browser that the vast majority of our visitors used, Microsoft Internet Explorer (IE) 5.0. We made that decision because we planned to include Dynamic HTML (DHTML), and implementing this document format in both IE and Netscape would have required a time-consuming testing and repair process that would add 80 percent to the cost of the site. The DHTML features we wanted included the background support for our new drop-down menus.
Sweep Out the Cobwebs
Modifying the layout and structure on our site was always a planned part of the upgrade. But a technology update became a priority too. Changing each page's database so that it uses common database functions made the site much easier to maintain. Moving to shared borders also simplified maintenance. Our new structure will let us upgrade the site one piece at a time in the future and will make a total rewrite go more smoothly.
