Save-State

What Saving-State is all about
Saving-state is shorthand for "Saving and Restoring State". You probably know what saving and restoring means - you do it with files that you save and reopen every day - but what does state mean? State is a general term that includes "everything about your situation" - and the specifics vary based on the application. In a word processor, the state of the application would include which windows are open, where they are on the screen, and what files you most recently used. In a web application, the state would include any data that you had entered, the results of any queries that you had run, and your security access information.

Why you need save-state
If you have a web site with only two (2) pages, you don't need save-state. That's because the fundamental nature of the web is to always pass data from one page to the next, and if you are lucky enough to only have two pages, then your second page will know everything from the first.

On the other hand, if your web site has more than two pages for the surfer to click through, and you want to be able to intelligently respond in various areas based on what the surfer has already done and told you, you definitely need save-state.

HTTP is stateless
This is adequate if you want to show only static pages, but it is completely unacceptable if you have an interactive site.

Think about it -- you've probably been to web sites where you had to rekey information; for example, entering your name and address to request information, and then having to enter it again to send a note to a sales rep. That happens because the site uses technology which does not completely/correctly save state. The consequences range from frustrated site users to lost sales.

WebHub tracks the surfer and adds state to HTTP
Before a web application can save-state, the application must first be able to accurately track the surfer as each page is accessed. Some systems (such as Cold Fusion and ASP) do this with cookies,which presents reliability and security problems. Since WebHub was first released in October 1995, WebHub has been tracking surfers through an anonymous number in the URL. This method is fast, easy and secure.

Session number and object
The number corresponds to a session object which is created automatically inside the application server. (Literally: when a new surfer comes in, a data structure called a session object is automatically created, and memory is allocated within that session object for that surfer's data.) The session object is kept on the web server machine - so the save-state mechanism does not travel back and forth with every page request, as it does in systems that use cookies or hidden fields.

The session object keeps track of :

1. all data the surfer enters into HTML forms (edit boxes, radio buttons, checkboxes, drop-downs and text areas)
2. the SaveState property of TwhWebActionEx components
3. any custom properties that are on the web session object

The first point makes sense to anyone use uses the web -- you want to have the web application remember whatever data is entered. The second and third points are more subtle, and get into the depths of the WebHub VCL architecture.

The time-sharing metaphor
The components (or objects) within all WebHub application servers are capable of remembering their own state. It's a little like time-sharing at a resort, where the component is the resort. A surfer comes in with a page request, and various components are used to create the page dynamically. For example, the TwhCycle component might get used to serve an advertising banner. The save-state mechanism makes sure that when the page is done, the surfer's session object remembers the state of that TwhCycle component. When the surfer comes back, no matter how many other people have time-shared that component, the state is restored so the component can accurately present the next ad for that specific surfer.

The bottom line is that WebHub saves state of all the commonly-required items and has an architecture which is by nature extensible, so that a VCL programmer can build in whatever additional surfer-specific properties may be needed over time.

WebHub Save-State demo
To see an example, bookmark this page then take a look at the Save-State Demo ("FORM"). It's a humorous example that shows exactly how much more WebHub remembers compared to a standard CGI or ISAPI application.

Cookies -- problems with refusal and security
A lot of systems use cookies as the way to save state. You can usually break those applications by refusing the cookie - try it at the next online store you shop at and see what happens.

There is the also the very serious problem of security. What if you logged into SecureTax.Com while you were at an Internet cafe and they had used cookies? (Fortunately, they don't -- they use WebHub instead.) If they had used cookies, the next person at the terminal could have gotten into your account (yes!). That's true at the office, too. Who uses your computer when you are away from your desk? Cookies are tolerable for information that is non-essential. They are totally inappropriate for secure facts.

For those developers who do choose to use cookies, WebHub does support them.