WebClasses - Extra Tuition
This column appeared in the July 1999 edition of EXE
and continued the coverage of WebClasses that was started in the previous
issue.
Last month I discussed the basics of WebClass technology,
notably the simple Request/Response model that facilitates the passing of
information from client to server and back. This month I am expanding this
topic to provide deeper coverage of this same issue, and also to explain how a
web-based application can retain state information. As before I will also be
including fundamental web development issues because there are still many
developers who have yet to make this step into the brave new cyberworld.
Sending client data to the server
Web pages are, more often than not, a one-way flow of data.
The user requests a specific page, for which a navigation request is passed to
the server, and then the next page is sent back down. Sometimes, however, the
user needs to send data up to the server, for example to send in registration
details for a newly purchased software product. This is implemented by setting
a section of the HTML page with form tags, specifically
<FORM>
and
</FORM>.
Within this defined region exist individual items such as text
boxes, radio buttons, check boxes, and so on. Two standard components that are
also used are a Submit button and a Reset button. The Submit button sends the
data that has been entered into the form up to a previously determined URL,
while the Reset button initialises the values of each control within the form
region. A single HTML page can contain multiple forms, but each separate form
will need to have its own Submit button.
The form tags themselves have a couple of parameters that are
worth discussing before we go any further. The syntax of the form tag is:
<FORM action=<value> method=<value>
name=<value>
</FORM>
To illustrate the point I have created a new HTML page called
RegData.htm and have added it to my WebClass project as a new WebItem called
GetRegData. Visual Basic has made a copy of my file called RegData1.htm. Using
this as a basis I can explain each parameter by giving an example:
The
action
property specifies the name of the target where the data from the form will be
sent. If you define your HTML page in a generator tool such as Visual InterDev
then this value will be empty when you initially define the form region.
However, once you import the HTML page into your WebClass project as a WebItem
the value will automatically be set for you, which is perhaps one reason why
Microsoft decided to give you a working copy of your original file.
The
method
refers to the manner in which the data will be sent to the server. Web browsers
generally support two different values for this property, called Get and Post.
To understand the difference between the two it is necessary to know that an
HTTP request can consist of just a header, or a header with a body. A header
can only store 1 kilobyte of data, whereas a body can – in theory anyway
– store an unlimited amount of data. The difference between the Get and
the Post methods is that the Get will only send the header, whereas the Post is
able to send the body as well. For this reason a Get method is often
unsuitable, and is in fact not supported by WebClasses. Therefore always
specify the Post method when designing forms for a WebClass target.
The
name
value merely identifies the form.
Putting this all together, we can now see a typical form
description (as generated by Visual InterDev, trimmed by me, and subsequently
modified by Visual Basic) that includes two text boxes, a submit button and a
reset button:
<HTML>
<BODY>
<H1>User Registration</H1>
<FORM action="WebClass1.ASP?WCI=GetRegData&
WCE=FORM1&WCU" id=FORM1 method=post name=FORM1>
<P>Please enter your details below:</P>
<P>Name:
<INPUT id=text1 name=text1></P>
<P>Email address:
<INPUT id=text2 name=text2></P>
<P><INPUT id=submit1 name=submit1 type=submit value=Submit>
<INPUT id=reset1 name=reset1 type=reset value=Reset></P>
</FORM>
</BODY>
</HTML>
Once the Submit button is pressed the data is passed up to the
target specified in the Action property as name/value pairs. I said earlier
that I had created a new WebItem based upon this form definition (which was
left with the default name of FORM1). When this WebItem was created Visual
Basic automatically created a new event called GetRegData_FORM1 which offers a
suitable point at which to extract the items of data that are being passed up.
This is done by calling the Form property of the Request object and supplying
the name of each required element in turn. For example
Dim sUserName As String
sUsername = Request.Form("text1")
Sending HTML to the client
The Response object is concerned with passing a stream of HTML
back to the client browser. This process can be performed by either dynamically
constructing an HTML page as I demonstrated last month, or by using an existing
template. In order to facilitate the need to return dynamic data along with a
predefined HTML page it is possible to insert special tags into the template
itself which can be substituted at run time with something else. For example,
you might want to include a page hit counter value at the bottom of your home
page.
Replacement tags, as they are known, are embedded within
source HTML pages. These tags need to be prefixed with a predetermined set of
characters, followed by a more descriptive suffix. Syntactically speaking a
prefix has to begin with an alphabetical character, and should also contain a
unique character such as the @ symbol. The default tag prefix is WC@, so it
follows that an example tag could be called WC@hitcounter. It is possible to
change the value of the TagPrefix property in the Properties window for each
WebItem. An example HTML page is shown below that includes two replacement
tags.
<HTML>
<BODY>
<H1>Centaur Communications Ltd</H1>
<p>Thank you for your interest in <WC@magname> our magazine
</WC@magname>.</p>
<p>The next issue will be available on <WC@nextdate> the first of
every month</WC@nextdate>.</p>
</BODY>
</HTML>
When the WriteTemplate method for this particular WebItem is
fired it will automatically scan the actual HTML source and look out for
anything beginning with the tag prefix. As soon as it finds something that
qualifies it fires the ProcessTag event in order to allow a substitution to
take place. At this stage you can alter the existing text that exists between
the tag markers. As processing of the source HTML template continues the
process is repeated for each subsequent tag that it finds. If you are expecting
more than one tag to be passed then it is best to use a Select Case statement,
as shown below
Private Sub Thankyou_ProcessTag(ByVal TagName As String, _
TagContents As String, SendTags As Boolean)
Select Case TagName
Case "WC@magname"
TagContents = "EXE magazine"
Case "WC@nextdate"
TagContents = "on the 1st of " & _
MonthName(Month((DateAdd("m", 1,
Now))))
End Select
End Sub
It’s worth remembering that the TagContents variable
initially contains the original text embedded between the two replacement tags,
which could be useful on occasions. The SendTags flag, which defaults to False,
determines whether the resultant HTML code will contain either the substituted
text still embedded within the tags, or just the new text. If the tags are
still included then the browser will probably ignore them so the end result
will still look the same. The product of our example code is shown in figure 1.
Figure 1: Internet Explorer showing substituted text
Maintaining state
By default WebClasses do not retain any state information
between instantiations, much the same as conventional Windows applications. In
the case of Windows applications such state information is either stored in the
registry, or in a database. It is of course a different matter with Internet
server-side components because there is no guarantee that a visitor will ever
come back again, so is it worth storing any information? Also, for how long
should such state information reasonably be stored on a server database?
Needless to say this is a different matter from storing user account
information, most particularly if you obtain a source of revenue from these
accounts.
State information is often of a trivial nature. For example
your web site might have a parallel set of pages that are optimised either for
Internet Explorer, AOL, or a Unix browser, or alternatively you might have
foreign language versions of your site. Either way it is more convenient for
the user if, when he revisits the site a bit later, he finds himself in an
initial page in which these preliminary issues (e.g. language) have been
retained and automatically configured.
By default a WebClass does not hold on to any information
between requests. Therefore if a user goes back to the same screen twice during
the same session then the default information will be presented on both
occasions – it will not have remembered anything about his previous
connection. This behaviour can be altered by a WebClass property called
StateManagement which can be changed from its initial value of wcNoState to
wcRetainInstance. This action changes the lifetime of the WebClass instance
from previously being alive for only the duration of the HTTP Request/Response
exchange, to being alive until either the WebClass calls the ReleaseInstance
method or until the preset timeout period elapses. The upshot of all this to
the developer is that your variables will either have data in or they will not.
The trade-off to this facility is system resources. As more instances of
WebClass objects are retained at any one time then the overall performance will
degrade.
Session and Application objects
Two of the other ASP objects are geared towards holding state
information, the Session object and the Application object:
-
The
Session
object relates to the logical connection that an individual user has to a
specific web application. When a new user connects to the web application a
SessionId value is generated which identifies the user. This value, called a
Cookie, is sent to the client machine and is stored by the browser. Then, for
each subsequent Request object that is sent, the SessionId value is also
included. If the browser has been configured for a high level of security then
it might not accept the Cookie, in which case no state information can be
retained.
-
The
Application
object pertains to a running instance of a specific application, regardless of
however many users are connected to it. It is created at the time of the first
user access to the web site, and then continues until the web site service
itself is terminated.
Both of these objects support the storage of variables. For
example, the Application object will be the logical place to record the number
of hits to a site. This object begins life by only holding one predefined
variable, called ~WC~WEBCLASSMANAGER. Additional variables for either of these
objects can be declared in a special ASP text file called Global.asa which
allows for such initialisation to take place. Space doesn’t permit me to
give any coverage of this specific topic, but I would refer you to the Active
Server Pages documentation in MSDN for more information. However the principle
here reminds us that the complete application resides as an ASP-based process
running within the context of Internet Information Server. The WebClass that we
produce is a DLL extension to the full application.
Using an Application-based variable the running total for the
hit counts to date could be incremented each time a new user shows up. This
code would be placed in the Start event for the WebClass, as shown:
Private Sub WebClass_Start()
Application.Lock
Application("hitcount") = Application("hitcount") + 1
Application.Unlock
End Sub
The Lock and Unlock methods combine to prevent other instances
from accessing this global value at the same time, and should be used for any
Application variable that could possibly be updated concurrently.
And that, in a very concise form, is the
basis of WebClasses. To make any real headway you need to have
more of an understanding of the ASP object model, and of course
you need to have at the very least a passing familiarity with
HTML. Microsoft have demonstrated by their assimilation of the
Internet into virtually everything that they produce that this
is an apparently unstoppable trend. Visual Basic developers keen
to keep their CVs up-to-date have little choice but to comply
with the need to become familiar with this whole area. Use these
two articles as a starting point, and then experiment.
