User Sensitivity 101
November 20, 2000
Let's again consider a page that we previously called a category two
-- it reads and takes advantage of user preferences cookies if present,
or else displays "guest access" content. We can think of a
couple of ways in which this manifests itself:
- First, suppose each page contains a navigation bar, and the links
in that bar are different for guests versus authenticated users. We'll
imagine that guests are merely identified as guests and provided with
a link to register; authenticated users may have links to edit their
preferences and logout, in our simple example.
- Second, suppose the fictional page in question contains some form
fields. Some of these forms are criteria for which the user has set
preferences, which are currently reflected in their temporary
site-prefs cookie. Logged in users, then, will see the forms
already set to their default preferences, while guest users will see
the forms set to generic defaults.
For the navigation bar, it makes sense to build another component,
navbar.html: navbar.html
<TABLE
width = "100%"
border = "0"
align = "center"
cellpadding=3
cellspacing=0
bgcolor = "#EEEEEE">
<TR>
[$ if $fdat{userid} $]
<TD align="left">Logged in as [+ $fdat{username} +]</TD>
<TD align="right">
<TABLE>
<TR>
<TD align="right"><a href="/editprefs.html">
Edit Preferences</a></TD>
<TD align="right">
<a href="/logout.html">Logout</a></TD>
</TR>
</TABLE>
</TD>
[$ else $]
<TD align="left">Logged in as <b>guest</b></TD>
<TD align="right">
<a href="/register.html">Register Now</a>
</TD>
[$ endif $]
</TR>
</TABLE>
The navigation bar is obviously a table, with one row. The embedded
Perl checks for the presence of a user identification value in
$fdat{userid} and if present, constructs a suitable series of
links. We can only imagine the files editprefs.html and
logout.html, but it's a fact that the logout script would work
by reissuing the site-auth and site-prefs cookies
with an expiration date of zero, effectively deleting them immediately.
A user with no discernable identification will see a different set
of links, as we see built in the else clause of this script.
The whole navigation bar can be plopped into a web page at any
appropriate position. Of course the read-cookies.html script
will already have been executed.
[- Execute ('read-cookie.html') -]
[- Execute ('require-login.html') -]
<HTML>
...some page code ...
...some place where the navigation bar should appear...
[- Execute ('navbar.html') -]
...rest of page code ...
As we said, this fictional page might also contain form fields that
coincide with some of those preferences currently stored in the
temporary site-prefs cookie. Imagine, for example, that
site-prefs contains a key named "telephone" with a
value being a telephone number. If this page contained a form for
contact information, we can imagine a form field with the same name:
<input type="text" name="telephone">
When read-cookies.html was executed, all of the keys and
values in site-prefs were loaded into %fdat. So, there
is now a value -- say, 555-1212, in $fdat{telephone}. Because
%fdat is a special Embperl variable, when Embperl sees the form
field named telephone in the source code it will automatically
insert 555-1212 as the field value. In effect, the form fields are
already filled out for the user in accordance with his or her stored
preferences.
Of course, a guest user without login cookies will have no %fdat
values, and thus the telephone field will remain empty.
Epilogue
As the sun sets on our trilogy of personalization, three truths remain:
database back-ends for long term memory, temporary session cookies for
short term memory, and Embperl for rapid development of user-sensitive
web pages. It really is more poetic than it sounds.
Cookies from the Oven
The Perl You Need to Know
|
