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 :
- all data the surfer enters into HTML forms (edit boxes, radio buttons,
checkboxes, drop-downs and text areas)
- the SaveState property of TwhWebActionEx components
- 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.
Save-State