Back in the times of DOS applications it wasn't difficult to implement program flows correctly. The user interface and the program execution flow where the same. If the user had the possiblity to make a choice, the code at this very place contained the required menu call. Immediately following the menu call, the code checked the return value and branched accordcingly.

With the appearance of Windows applications this became significantly more difficult as the user could open multiple forms at the same time. It's still simple to implement sequential processes. Windows use "wizards", for instance, when installing most Windows applications. The user enters data in one page. To skip to the nex page they hit the Next button. This concept has a number of requirements:

·     Only one user at a time can work with the form

·     A form always remain a single form. You might be able to open multiple instances of the wizard. Yet, those are clearly separated by their own set of properties and their own datasession.

·     The user can only move to a limited set of pages, usually the previous and the next one.

Web applications do not fulfill these requirements. No AFP instance is dedicated to  a specific user. Quite the contrary, each user might be distributed among multiple instances. To complicate matters a use can open multiple browser windows, yet still use the same session in all of them. He even could use different browser in a single session like requesting a form with Internet Explorer and sending the result with Opera back to the server.

Hence, data that controls the program flow doesn't belong into session variables. Even though, this might look like a good idea at first glance. The tricky part here is that it seems to work during testing because you usually only test a single user that completes the entire process correctly. Usually, the exceptional branches of the flow are not tested.

In most AFP documents a decision is made to which page a user can navigate to in the next step. This decision is based upon static and context-dependent conditions. Examples of static conditions are:

·     A link "Edit profile" is only available after the user logged on

·     If there's server maintenance scheduled within the next 48 hours the page reminds the user of this fact.

·     User with a particular browser get a different style sheet definition

All these conditions have in common that they don't depend on which page the user is currently viewing and which choices he makes. Such information are good candidates for session variables. A logical glLoggedIn variable might be set to .T. after the user successfully completed the login.afp document. The existence of a file can indicate maintenance tasks. Request.ServerVariables() tells you everything about the browser.

With context-depended conditions the page decides which options are available:

1.  A page contains a pageframe. The current page determines what the content is.

2.  A user picks a record from a list of matching records and edits the record.

3.  To check out a user must specify shipping addresses, payment details, etc. in a series of steps.

4.  A user modifies or adds a record

Each of these four samples corresponds to either an action on a form or a state in a conventional desktop application. In a web application you can implement these samples in multiple ways.

More:

Display multiple pages in a page frame