Page #54 (Chapter 7 - Controlling Program Flow)

Chapter 7 - Controlling Program Flow

Visual Basic Developers Guide to ASP and IIS
A. Russell Jones
  Copyright 1999 SYBEX Inc.

Understanding Program Flow
Have you ever tried to read a hypertext novel? In a hypertext novel, Chapter 2 doesn't necessarily follow Chapter 1. You are at perfect liberty to read chapters in random order, in linear sequence, or any combination. As you can imagine, the plot of a hypertext novel—and the planning that goes into it—are considerably different from the plot or the plan for a standard, sequential novel.
The Web is a hypertext medium. It is meant to be a hypertext medium, and although you can force pages into a linear sequence, you are working against the natural order of things. When you write a Web application, you need to change the way you think about applications because Web applications run in a nonlinear medium. The harder you try to force your application to behave like a Windows application, the harder you will have to work. Sure, you can use a customized Web-browser control or Java to write your applications, but only by hiding the standard browser controls, menus, and functionality. My advice is to take advantage of the browser and the Web; don't fight them—work with them.
The track a person takes through your application is called program flow. As a programmer or application designer, there are times when you don't care about program flow—you're perfectly happy to let the user control the path through the application. On the other hand, there are times when you absolutely must control the track a user takes. For example, in a testing program, you may not want a user to be able to back up and change the answer to a previous question. The program flow in this case is forward only. When your application has complete control of the client computer, controlling flow is relatively straightforward. When your client computer is a browser that is connected to your program only through an intermittent Web connection, controlling flow is more difficult.
The basic problem with controlling program flow on the Web is that browsers can move from place to place using Uniform Resource Locators (URLs). At any time, a user can type a URL into the address field, and the browser will attempt to navigate to that page. That's one difference between a typical Windows application and a browser-based application. In a Windows application, users can't move from one screen to another unless you provide them with the control (for example, menu selection, button click, list selection, etc.) to do so.
A standard Windows program spends most of its time looping, waiting for mouse or keyboard activity. You can assume that as long as your program is running, the potential exists for user interaction. Even if the user gets up and goes away for the weekend, leaving your program running, it still sits there spinning, waiting for specific events. One important event that your program will recognize is the user's desire to quit. Typically, you provide a Close or Exit option on the File menu. You also trap other methods through which the user might quit, such as closing the window or shutting down Windows. The important concept here is that the only way the user can exit your program without you knowing is to shut off the power to the computer.
In contrast, a Web application has no concept of waiting for user input because it's running on the server, where there is no user input. The browser interface portion of the program may still be running—but you can't know that. Consequently, you can't know when the user has closed your program, either. Therefore, server applications tend to time out after a definable period of inactivity.
In addition, in a typical Windows program, the program always moves "forward." Even if you provide a Back button, as in a Wizard, you know when users are moving backward because you know that they pressed the Back button. In a browser-based application, users always have a Back button. They also have Favorites and a Refresh option. You don't typically know how a user got to a page in your application; therefore, when you want to control where they go next, you need to track their progress so you'll first know where they are now. Given that information, you can decide whether the user is trying to move backward, forward, or simply trying to refresh the current page.
This is a difficult concept until you begin to work with a browser as your application host, and it's easier to see than to explain. The best way to understand it is—you guessed it—to create a project and explore it with the debugger. You'll do that in the next section.



Visual Basic Developer[ap]s Guide to ASP and IIS
Visual Basic Developer[ap]s Guide to ASP and IIS
ISBN: 782125573
EAN: N/A
Year: 2005
Pages: 98

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net