Drew Wutka
DWUTKA at marlow.com
Wed Nov 26 16:54:33 CST 2003
Paul, I have been developing ASP project for quite some time now. I think I
can narrow down what you REALLY need to know to get started.
First of all, before you dig into web development, you MUST understand how a
web server and web pages work. It is a whole different ball of wax compared
to an Access FE. With an Access FE, you create forms and reports, and each
user has a copy (or uses a shared FE) of the front end. This has several
drawbacks. First of all, if you have copies of the FE all over, you have to
create an update process to push out new changes. If you have a shared FE,
then you have to kick everyone out to update the process. On top of that, a
user can be anywhere, so there can always be issues of where things are
located. One user may have a share mapped to S, while another has it mapped
to T. UNC's can handle this, but then there is also the issue of whether
people are able to even get to the locations involved. On a web server, all
of these issues are moot.
The way a web server works, is the client opens their browser and requests a
web page. Let's say they go to http://MyWebsite.com. The browser does a
few things, one of which is it sends an http request to the server sitting
at whatever mywebsite.com resolves too. (http is Hyper Text Transfer
Protocol. HTML is Hyper Text Markup Language. So, HTTP is the protocol
uses to transport HTML.). The server at the other end gets an http request
for it's root directory. Notice the URL doesn't have a specific file (this
is a KEY point to remember). That is just fine and dandy, because a
webserver can be asked for a page by just the 'folder', since each folder
can have a default document setup. In most cases it is index.htm or
default.asp, but it can quite frankly be any document you want (or even a
list of documents). For our example, let's say it's default.asp. The web
server then reads the default.asp page and runs it through it's ISAPI
filters. These are filters that cause various things to be done to the HTML
that is going to be sent back. Two good examples of this are includes and
ASP itself. Includes are when you mark another file or files to be included
within the document. So, if you have a header that you want on every page,
instead of putting the HTML for that header on every page, you put the
header in it's own file, and just include it in all of your pages. The
include ISAPI filter then incorporates that HTML in the outgoing HTML. You
can also include .asp code, similar to putting code in a module, versus
behind every form/report. The ASP ISAPI filter is a little more complex.
Instead of just replacing text, it actually 'works' the ASP code on the
page.
This is the CORE of ASP. What the end user get's, is just the outgoing
HTML. They never get the ASP code itself. ASP can either be passive or
dynamic. My own terms for the two actions ASP can perform. Passive is when
the ASP does something that the users can't see. Dynamic is when ASP does
something that the users DO see. For example. If the default.asp page was
like this:
<%
dim cnn
dim rs
dim strSQL
set cnn=server.createobject("ADODB.Connection")
set rs=server.createobject("ADODB.Recordset")
cnn.Provider="Microsoft.Jet.OLEDB.4.0"
cnn.Open "E:\MyDB.mdb"
strSQL="SELECT Hit FROM tblHits;"
rs.Open strSQL,cnn,1,3
rs.AddNew
rs.Fields(0).value=1
rs.Update
rs.close
set rs=nothing
cnn.close
set cnn=nothing
%>
<HTML>
Hello
</HTML>
The end user will get a page that says hello, but internally, the ASP page
has added a record to a database, in this case, a simple hit counter. This
is passive, since the user will always get 'Hello', no matter what they do.
The ASP code is doing work, but it's something the end user doesn't see.
Dynamic ASP pages are where the output the user sees is directly affected by
the ASP code. To do this, you must either use the = symbol (which is a
shortcut to have the ASP send something out with the resulting HTML stream),
or the response.write procedure.
For example, let's have default.asp be this:
<%
dim strIP
strIP=request.ServerVariables("REMOTE_ADDR")
%>
<HTML>
Your IP Address is: <%=strIP%> <br>
<%
response.write "Have a nice day."
%>
</HTML>
What the user will see is a message that has their IP address, like this:
Your IP Address is: 65.65.125.209
Have a nice day.
We used the equal since to 'insert' something into the normal HTML with ASP,
and then we used response.write to directly output a string into the
outgoing HTML stream.
The last thing to remember when dealing with a web server is that the end
users are getting whatever the web server hands out, the moment they request
it. Once they get the resulting HTML stream, and their browser displays the
page, there is no longer a connection to the file they requested. That
means if you are constantly updating asp pages, the end users will just
simply get the 'current' results at the time of their request. No kicking
everyone out, etc. Pretty handy.
Three more items to cover. Above was the biggie. First of the three. HTML.
HTML is actually pretty simple. I personally used Front Page when I started
out, to let it do the HTML for me, then after a few months of going back and
forth, I just got the hang of it, and I rarely ever use FP for writing the
HTML anymore. The two key items to remember with HTML is that everything is
written with tags. Some tags are stand alone, such as <BR> (which is a line
break), and some tags must have a start and finish (<HTML> and </HTML>, or
an easier example <b> and </b> which is for bolding text). Tags also can
have properties. For example, an anchor tag (for hyperlinks) is a. <a
href="http://wolfwares.com">Click here to go to Wolfwares.com</a> <a starts
the tag, it has an href property, which is the URL of the site/file the
hyperlink points too, then the tag is closed with the >, and between the
start tag, and the closing tag </a>, there is text, which is what the user
will see as the text of the hyperlink. The second key item to remember with
HTML is that no matter what format you write the HTML in, what the user sees
in the browser is determine by the TAGS, not by the HTML code.
So if you write:
<HTML>
This is a
Test
</HTML>
The user sees:
This is a Test
If you write:
<HTML>This is a <br>Test</HTML>
The user sees:
This is a
Test
Second of the three is a BIG difference between Access and ASP. Access runs
it's code on the users processor. This is both good and bad. Bad, because
the end user must have Access (or a run-time installed). Also, bad because
users on slower machines are going to be delayed longer then users on fast
machines. Good, because as long as the end users have the correct
software/runtimes, your application should almost be gauranteed to work.
With ASP, if you write standard HTML, it doesn't matter what you have the
ASP code do. Your ASP code only has to run on the web server. Your clients
can be running Pentium 4's, with IE, or Mac's with Netscape, and everyone
sees the same results. A client running a 2.6 gigahertz on a 56k modem is
going to run your application at the same speed (well, pretty much the same
speed) as a client running a 486 66mhz with a 56k modem. In fact, if your
pages are light enough on the output (little to no graphics, just plain
HTML.....) there isn't going to be much of a difference between a modem user
or a broad band user. Text transfers pretty quickly....though you could have
slow downs if there is just a ton of text being sent (like combo boxes that
have thousands of items in their lists). The final issue with this part is
client side scripting. I personally stay away from it like the plague,
unless it's for in house projects where I know everyone is using IE. So try
to make your applications run strictly with ASP, unless absolutely
necessary.
Third of the three. The real nuts and bolts of ASP. ASP can be written in
JScript or VBScript. Quite frankly I have never bothered to use JScript,
since VBScript is practically second nature. When writting ASP, you enclose
the ASP code with <% and %> (start and end tags for ASP), and then write
away with VBScript. There are two things to remember/research. ASP is
VBScript with extra objects (Application,
ObjectContext,Request,ASPError,Response,Server,Session). The three you are
going to deal with the most are Request, Response and Server. Request gives
you access to what you have been 'sent' by the user. It can be used to read
cookies, server variables (which include Usernames, passwords,IP Addresses,
browser types, etc.), and form data. Response is what you use to send data
back to the user (response.write outputs to the HTML stream, redirect can
actually change the URL the end user is receiving, etc.). Server is the
webserver itself. The two main methods you will probably use are
MapPath(Which let's you map a virtual or actual path to a file) and
CreateObject. That CreateObject is the big catch with ASP and VBScript. In
normal VBScript you just call CreateObject. But with ASP, you must use the
Server Object's CreateObject method to create an object in VBScript.
(Because the object must be created by the webserver).
That's ASP in a nutshell. The first item I talked about is a little
difficult to figure out from the MSDN, the rest is in the MSDN, but can
still be a little difficult to figure out. The details on everything (HTML
tags, ASP objects, etc.) are pretty much well explained in the MSDN though.
The last thing you will need to know about ASP pages versus Access FE's is
how to get data FROM the user. (we already discussed sending it to them,
with the response.write method). I mentioned the request object. The two
methods of getting data from the user are through forms and querystrings. A
querystring is what follows a URL (after a ?). So, if you have a URL like
this: http://MyWebsite.com/default.asp?MyValue=10 , you can retrieve the
value of MyValue by using the request.QueryString method, like this:
<%
response.write request.QueryString("MyValue")
%>
If you have an HTML form, and you POST the data:
<HTML>
<BODY>
<Form Name="MyForm" Method=post action="results.asp">
<input type=text name="MyValue">
<input type=submit>
</form>
</body>
</HTML>
The resulting page will have a textbox, and a submit button. Pressing the
submit button will send the data within the MyValue textbox to results.asp.
So if results.asp was this:
<%
response.write request.form("MyValue")
%>
The results page will output whatever was in the textbox.
The key difference between a QueryString and a Form is that QueryStrings are
limited by the max length of a URL (which is, I think, 2048
characters...maybe 1024 characters, not sure). Where as a form is not
limited in the amount of data that can be submitted. You can also refer to
a request 'variable' by just the request object. request("MyValue") can be
a value in either a QueryString OR a Form.
Phew, what an email. This was fun to write though. Keep in mind that ASP
doesn't directly like DAO, so write your code using ADO. Feel free to
contact me offlist if you have specific questions. I may get hammered for
the length of this email, but I think it's pertinent to Access development
on the web!
Drew
-----Original Message-----
From: paul.hartland at fsmail.net [mailto:paul.hartland at fsmail.net]
Sent: Wednesday, November 26, 2003 9:55 AM
To: accessd
Subject: [AccessD] OT - Getting started with Web development
To all,
I'm looking to start writing web pages etc, secure logins, returning
resultsets in tables from Access & SQL Server etc.
Anyone know any good sites to get me started along with any book
recommendations ?
Thanks in advance for all your help
Paul Hartland
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com