Browser-Related
Gotchas
Internet
Explorer is Better Than Netscape For Testing
Even if you build to a Netscape standard, test on both the Internet
Explorer (IE) and Netscape platforms. In Netscape, asp and sql errors
tended to be 'silent': the status bar indicates that the page has loaded,
but all you see in the browser window is a blank screen. In Internet
Explorer, the page loads and the appropriate, numbered SQL, VBScript
or JScript error appears in its entirety in the location where the error
was fired. The page stops loading at the point where the error occurs,
but you can view the number and text description of the error and you
also know where in your code to start looking for the problem. If you
don't have IE, get it!
Netscape
4.61 Is Picky, Picky, Picky
I can't speak to version 6.0, but Netscape 4.61 can be a real fussbudget
when it comes to properly rendering the HTML embedded in asp pages.
Consider the following:
1.
Netscape 4.61 will not render an HTML table cell at all if the cell
is empty; you must be sure to insert the non-breaking space code ( )
in every table cell or else you will end up with "holes" in
your tables wherever blank cells should appear.
2.
Netscape 4.61 requires explicit <FORM> tags in the body of the
HTML section. In IE, the standard "Form Processing" block
of script in the head of the page is adequate, but Netscape 4.61 either
can't or won't read that block of script and will error out on you,
returning a "Permission to Virtual Directory Denied" error
message in the browser window. If you want your pages to work in Netscape
4.61, explicitly declare the start and end of each form in the body
of your HTML.
3.
When an application has NT- or Novell-integrated security, Netscape
pops up an annoying little login box for the user to re-enter their
network login ID and password. Just having the box isn't annoying in
and of itself, but the fact that the box contains a very cryptic prompt
that cannot be customized is VERY annoying. The login prompt asks the
user to "Enter username for [server name] at [server name]".
It is not apparent to the user that he is supposed to enter his network
login ID and password, so this becomes an ongoing training issue. In
IE, by contrast, authentication is seamless and invisible to the user.
There is no login at all; IE fetches the user's current network login
information from the network and checks to see if the logged-in user
is a member of the security group he or she is trying to access. If
he IS a member, access is granted without so much as a confirmation
message echoed to the user. If he IS NOT a member, access is denied
and the user is either redirected to a custom Permission Denied page
(if the developer built this custom page and has the redirect set up
at the web server) or the user is shown a generic "Forbidden"
browser message.
4.
Netscape 4.61 is completely unforgiving of HTML errors, while IE does
a very good job of weeding out duplicate tags and making correct assumptions
about what you were trying to do in your page. IE's benevolence is good
AND bad; good because it hides your mistakes from end-users, but bad
because it also hides your mistakes from YOU.
Given
the above, plus all the other browser-related gotchas I haven't even
discovered yet, I highly recommend cross-browser compatibility testing.
It's the only way you can be sure that your application will behave
properly regardless of the client browser and even if you're sure your
app will only be used in one of these two browsers, testing in the other
browser will help uncover page errors.
ASP
Gotchas
The
Request.Form Object & Pages That Post to Themselves
When
you have asp pages that post to themselves for form processing, be careful
with your Request calls. Remember that Request.Form("fieldname")
syntax should only be used if your code needs to access field values
from a DIFFERENT page; if your page posts to itself and you need to
fetch or validate field values in the current page, use Request("fieldname")
syntax. This is a very simple little thing that is easily overlooked
if you're in the habit of coding an entire page before beginning to
test it.
Beware
the User
Users
are very hard to control in a web application environment. They can
jump directly from page to page by typing a URL into the address field
of their browser window, and they can exit your application entirely
by any number of means: typing in a different URL, using a stored bookmark,
dropping down the history box and selecting an item from the list, etc.
Keep this in mind when designing pages with required fields, pages in
which there are dependencies between fields, or pages with security
or some form of pre-load authentication.
I've
found that pages with required fields or field interdependencies are
fairly airtight if you force the user to enter all the fields, and then
validate all of the field entries, BEFORE saving ANY record changes.
To prevent the user from saving mismatched data, I make all fields required
fields by coding in Request commands and errors for every field into
the asp code in the page header, then I perform extensive field validation
in the code and do not go on to UPDATE or INSERT the record until the
user's entries pass all field validation tests.
Use
of a server request for logged-in user information, coupled with a Response.Redirect
and a custom error page, is useful for dealing with users who try to
jump to a secure page without logging in or passing other authentication
tests. If you're using application-level security (as opposed to NT/Novell
integrated security), you can add code to all your secured pages to
"see" who's currently logged in, validate that user's access,
and if validation fails, redirect the user to your login page or a custom
error page.
Field
Validation Involving the SQL Bit Data Type
I had a lot of trouble getting my field validation code to work where
fields were of the Bit datatype.
For
anyone unfamiliar with that datatype, it's the SQL 7 version of a true/false
or on/off field. A Bit field can only contain one of two values: a zero
or a one. If it contains a one, the field value can be considered "on"
or "true". If it contains a zero the field value can be considered
to be "off" or "false". Bit fields are valuable
because they save a lot of space and processing overhead in your database
--- checking for a zero or one is easier and faster than checking for
a string text value of "true", "on", "yes",
"false", "off" or "no".
There
are some peculiarities to deal with when coding around Bit fields, however.
1.
Even though the values of "1" and "0" represent
statuses of "true"/"on"/"yes" and "false"/"off"/"no"
respectively, your field validation code must compare against the literal
values of "1" and "0", NOT against any of the statuses
those values represent. Before you start rolling your eyes and whining,
"Well, duh!", check out item #2 below.
2.
While it's true that you cannot use the statuses of "true"
or "false" to validate the contents of Bit data fields in
your asp code, if you display a Bit data field value in your page (i.e.,
<%=recordset("aspfieldname")%> ), the page will display
text reading "true" or "false", not "1"
or "0". Now re-read item #1 above; do these two items seem
contradictory to you? They certainly seem contradictory to me.
3.
Because asp will translate the Bit values of "1" and "0"
to "true" and "false", respectively, you cannot
default a data entry field for a Bit database field to the value supplied
by asp. If you do not supply the acceptable values of "1"
or "0" instead, you will receive an error when you try to
update the field contents because you will be trying to update a Bit
data field with a literal value of "true" or "false".
This means that where users are given a choice of yes/no, true/false,
on/off for a given field, you will need to provide them with a dropdown
select field where the list VALUES are "1" and "0"
but the list TEXT ITEMS are something friendlier and more meaningful
to the users.
For
example, a Bit field called 'Fulltime" in my database is used to
indicate if an employee is full- or part-time. The users make their
selection from a dropdown list that has two text items, Full-Time and
Part-Time, but the values of those fields --- the data that will actually
be written back to the database --- are "1" and "0".
A value of "1" indicates that an employee IS Full-Time and
a value of "0" indicates that an employee IS NOT Full-Time.
Since the only other option in Part-Time, any employee with a Fulltime
field value of "0" is assumed to be Part-Time.
4.
When validating against Bit data fields, don't explicitly declare the
value you are comparing against. In other words, where you would expect
to write an If statement that looks like this:
<%
If MyRecordset("Fulltime") = 1 Then
Response.Write
"Full-Time"
Else
Response.Write "Part-Time"
End If
%>
What
you would actually write (if you wanted your code to work, that is)
is this:
<%
If
MyRecordset("Fulltime") Then
Response.Write
"Full-Time"
Else
Response.Write "Part-Time"
End If
%>
Or
conversely, you could write it as:
<%
If Not MyRecordset("Fulltime") Then
Response.Write
"Part-Time"
Else
Response.Write "Full-Time"
End If
%>
Notice
that the correct syntax is "If" or "If Not" when
you're checking against an on/off, yes/no, true/false field value. To
me, this seems like yet another flavor of inconsistency. I mean, if
the literal field value is a "1" or a "0", I don't
see why you shouldn't be able to compare against those literal values
just the same as you would with any other data field. But trust me,
I tried it, and it doesn't work.
