Chapter 6 - Session, On-the-fly transmission objects.
When users "surf the web" most of them are not aware that they are always making and breaking contact with websites. Web sites stay connected for only as long as it takes to feed us the requested documents, pictures and media and then we look at the copies of this material now parked temporarily in our machine's local memory. Moving from Chapter 5 to Chapter 6 of this book is a complete new re-connection, and the fact that you are "already here" gives you very little speed advantage over someone linking to it as new from a quite different web-site. Such a protocol has its advantages for simple actions such as passively reading documents and it conserves bandwith well. Figures like 1000 plus visitors "hitting" a web-site at once or "a million hits in one day!" are not as dramatic as they look. Most visitors will only be working the system for a few seconds to get pages which may keep them occupied for minutes of reading time. That million hits in one day could translate to between 10 and 500 users actively connected at any one time, and any Web event that pulls a big crowd also causes devices like "caching proxy servers" to kick in all through the communication channels and help out with feeding local copies of repeating transmissions like pictures.
Enter the "Session Object" which is a little like the PICK "Common" block. In most cases, serving the user a new on-screen document "re-invents the wheel" in that it is like user breaking the connection and logging on again. "Session" remembers the user identity in-between the making and breaking of contact and acts like a continuous proxy representing the user inside the IIS Webserver.
"Session" can store user session variables and values that need to be remembered as we move from page to page. This is the purpose of most interest to us.
In June 1999 we found a good job for Session. It came from building a "Privilege Area" on our site where we offer extras, mainly downloads, only to users who have given us their names and contact details through the User Registration covered in Chapter 5.
When a new user registers or an existing user does a successful login, we script:
Session("UserID") = sUserID
Note that "Session" supports "named arguments" which means that you can create your own variables on the server with this syntax, no other declaration statement is necessary.
Then all "Privilege Area" content is delivered by asp scripts which start in this general way:
sUserID = Session("UserID")
If VarType(sUserID) <> vbString Then sUserID = ""
If sUserID > "" Then
Call DeliverContent
Else
Call UserNoAccess
End If
Note the use of VarType to detect the situation when a non-logged-in user
tries to access a protected resource.
Session("UserID") returns an "Empty object" which is not a string, and needs to
be recognised and converted to a string to work in the following If
block(s).
It is a very similar situation to the classic PICK clanger of
"[B10] variable is not assigned a value, zero
used"
We usually set a "Session Timeout" of 15 min which means that after 15 min of no activity in the app, the user login expires.
"XML Download Behaviour" or "IFRAMEs" as dynamic "on-the-fly" communications devices
When I showed my first Web experiments to my PICK colleagues, they were not pleased with the way the Web "makes and breaks" along with its deeply embedded standard that the browser document window completely clears on any exchange of data with the Server. Therefore the common Web App programming model is based on expecting the user to complete a screenful of data entry, then send the lot in for processing in one form-submit batch. This was common practice with IBM mainframes and terminals in the 70's and 80's and my colleagues did not like it then and they don't like it now! The objection is the lack of validation-as-you-go. It is too easy to make an error in data entry that ruins a screenload or more of typing and not know about it until after a lot of time is wasted.
Other objections include:
The challenge was on to make browsers act more like terminals.
Our work up until early 2001, was based on Microsoft's "Remote Scripting" technology. Quoting from http://msdn.microsoft.com/scripting
"With remote scripting, developers can now create seamless,
interactive Web applications in which the browser can call
scripts on the server without reloading the Web page.
Prior to remote scripting, developers would have to require
the user to reload the calling page, often several times,
to interact with the server.
This created a slower, disjointed, user experience and
inefficient use of the server."
"Remote Scripting" worked well for us, but required additional installations on the Webserver and the use of some complicating additions to the user session, eg the loading of an "RSPROXY" Java applet. "RSPROXY" supports IE4 and above. Netscape 4 can be handled with considerable difficulty. But Netscape 6 is a no-go.
Internet Explorer 5 and above have a suitable transmission method
built-in, the "XML Download Behaviour".
This is fast, and makes for much simpler App installation on the
Webserver. The App only depends on the basic features of IE without any
issues around Java as an optional extra.
The "XML Download Behaviour" has become our preferred method, but we do have another slightly slower but more flexible one. Our Web App templates are easily changed to the "ARRAY OF IFRAMEs" method. The use of separate invisible windows ("frames") to take the hit of being erased at each conversation step is an old idea. We have been experimenting with it since late 1998. Its main problem is that it fails to manage requests in queues, as in a user working fast from field-to-field can cause new transmissions to destroy earlier ones in progress. We have recently solved that problem by using 3 IFRAMEs which rotate in turn at being the transmission device. In theory, the ARRAY OF IFRAMEs demands more processing power from the client. In practice, most recent machines, ie over 300MHZ in speed, can run it almost as fast as the XML Download Behaviour. Apart from supporting IE4, the IFRAME object is now available in Netscape 6 so at the time of writing we are working on translating our client-side BASIC vbscript template page into JAVASCRIPT to support Netscape 6 as well.
Protocol
A transmission method needs something meaningful to transmit.
Chapter 7 (next) documents our protocol. In brief:
Example Server transmissions:
GROWINS|gx8x3
- insert a new row into grid number 8 above row number 3
VALID|fx3=John -
color field fx3 green to show validation and display "John" in it
VALUE|fx3=John^FOCUS|fx6
- display "John" in fx3 and focus on fx6
Example Client transmissions:
fx3|Andrew - user has entered "Andrew" in field fx3
One of the things we like best about Field-by-Field is that it
widens the advantage gap that PixieWeb has over its most obvious rivals, the
UVObjects and PICK Objects.
You get the most advantage out of on-the-fly transmission with
continuous conversations with one DATABASIC program handling one web page, much
like the relationship with terminal screens. The UVObjects etc can only do
one-off calls against specially compiled subroutines and they can not maintain
an ongoing conversation with a BASIC program. Note
that PixieWeb can and with these methods available we have a "marriage
made in heaven" where that capability can really fly, effective making a web
browser an attractive GUI replacement for terminals.
Notes on other features of IIS
Global.asa
This is a file in which you can set "global values" across all scripts in the
application. I don't like it, it seems to do strange things to some of my
scripts and it can also cause values to "lock in" and require you to shut down
and restart your Web App to clear out the resulting rubbish. Since I often seem
to be working remotely on my Web Apps, this can be a big nuisance. I prefer to
set Session values within my own asp scripts.
In my opinion, you can achieve much the same effect with "#Include" or
the new
Pixie.FileGetText
function and get better flexibility.
#Include
This very PICK-like technique, can help get over the tendency to repeat similar
blocks of code in .asp scripts, and means you can make changes to values like
Server Name in just one place.
eg you can take something like this:
Set Pixie =
Server.CreateObject("PixieWMA.clsAgent")
Pixie.TimeOut = 6
Pixie.Port = 23
Pixie.Host = "127.0.0.1"
Call Pixie.Connect("{AUTO}")
Call Pixie.ExecuteET("testuser", "<<< Pick Systems")
Call Pixie.ExecuteET("term mm-mon", ":")
Call Pixie.ExecuteET("echo off",":")
... and copy it to a file named PixieConnect.txt
Then, in all .asp scripts where it appears, replace it with:
...
%>
<!--#include file="PixieConnect.txt" -->
<%
...
NOTE that you need to close any previous block of script with
"%>" and after the #include
begin any further script with "<%"
Next: Chapter 7 : Resources for field-by-field apps.
Appendix: summarises PixieWeb object properties and methods.
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 ** Top ** Chapter 7 Chapter 8 Appendix