The Back End
July 10, 2000
Before we actually start building the submission system, we'll want to
create the database backend. The tables we'll create will store
important information about the content. Here's a sample database
structure for the submission system we're creating:
|
tblFiles |
|
UID |
Unique ID to keep track of records |
Autonumber |
|
Filename |
The filename of the document |
Text |
|
Author |
The name of the author |
Text |
|
Title |
The title of the document. (Note: This is not the same as the filename.) |
Text |
|
Date |
The date of the publishing/writing |
Date/Time |
| Published |
Is this document published (ie viewable to the general public?) |
Boolean (Yes/No) |
You can obviously expand this with whatever you'd like, but this is
a good framework to start us off.
Functionality
We will use a wizard type interface here - that is, the user selects
some options, hits the next button, selects some more options, hits
next again, etc. This will make things much easier to follow for the
user, and much easier to debug for the developer. How do you design
a wizard? Simply follow these easy to munch on steps:
- Each step that we discuss below can be on a single page.
- Any forms on those pages (and there will be a lot) will point to
the same page (action will be set to the same page the form is on).
- Put the script that processes the form somewhere on that page,
preferrably at the top.
- After the script is through, and if it is successful, redirect the
user to the next step.
For example, here's some sample pseudo-code from a file called
form.asp:
<%
some code to process form
some more code
.
.
.
if code is successful then
Response.Redirect("form2.asp")
End If
%>
<html>
<form method="post" action="form.asp">
some form elements
some more form elements
</form>
</html>
This method is cleaner than setting form actions to different pages,
allows for a wizard-style interface, easy form validation, and allows
you to easily direct the user to incorrectly inputted form items.
Submission Step 1 - Putting it on the server
Let's assume that content is already written and is in some
text-compatible format. How do you get the file on the server? Well,
there's two ways to do that. You can either:
1) Give all your writers FTP access so they can upload the file
themselves or
2) Build a web form
There are plusses and minuses to both methods. Both methods require
special permissions: method 1 requires FTP write permissions, while the
second method requires either the user to be logged onto the server or
HTTP write permissions. Also, with the first method, the upload process
must be done separately from the management steps, and you'll have to
supply the management system with the exact file name later. The second
method will (or at least should) supply you with the exact file name
and can be part of the whole system.
If you decide to go the second route, you'll need either a COM object
or some strong knowledge of HTML binary form submission. Two common
COM objects used for uploading files are:
SA-Fileup
ASPUpload
But these can be rather expensive. A wonderful free one that I've used
before is:
EZ Site Upload Lite
There's a great tutorial over at
15 Seconds.com
on how exactly to upload files, so I won't explain it here. If you're
a clever programmer and know the nitty-gritty of HTML form submission,
then you may be able to create an ASP script in place of the COM object.
If you decided to make your writers submit their articles into a web
based form, then you don't need to know about those COM objects
above (but aren't you glad you read it anyway?). Instead, have your
writer type or cut-and-paste his article into a textarea element on a
web form. Then simply use the file system object (check out
4GuysFromRolla.com
for a great tutorial on the file system object) to write that file on
the server.
Okay, so the file is up. Now what?
If you followed step 2 from above, your ASP script should know the
file name. If not, you'll have to build an extra step to ask the user
for the file name. Once you get it, you'll want to store that filename
(and maybe the absolute directory the file is in) in the database, so
you don't forget it. The following code will enter the filename into
the database: (note that the SQL statement uses the table name we
created above).
<!--#include virtual="/scripts/adovbs.inc" -->
<%
set connFileName = Server.CreateObject("ADODB.Connection")
set rstFileName = Server.CreateObject("ADODB.Recordset")
connArticles.Open "dsn=my_db;DATABASE=my_db"
strSQL = "SELECT * FROM tblFiles"
rstFileName.Open strSQL, connFileName, adOpenKeySet, adLockOptimistic
rstFileName.AddNew
rstFileName.FileName = "blah.html" <--- Substitute actual file name here
rstFileName.Update
intID = rstFileName.UID
rstFileName.Close
set rstFileName = Nothing
connFileName.Close
set rstFileName = Nothing
%>
NOTE:
adOpenKeySet and adLockOptimistic are Visual Basic constants. They
are not readily available to the ASP environment, meaning that if
you try to use the code above, you'll probably receive an error on
the rstFileName.Open line. You can do one of two
things: either use the numeric values of those constants, ie,
adOpenKeySet=1, adLockOptimistic=2, etc (but who can remember all
those values?); or include the file ADOVBS.INC in the page. This
file is usually located in the scripts virtual directory of the
web server. If not, hunt around, it's there somewhere.
|
Now you have a means to access the file later. Before you move on
though, you'll want to know which document to use in the next step.
Since the form on this page was self-referencing, you can't call a
Request.Form in the next step to figure out the ID number
of the document you just submitted. Instead, at the end of the of
redirect URL, attach a querystring with the ID number, using intID that
we created above:
Response.Redirect("step2.asp?ID" & intID)
Now when you need the information in the next step, just do a
Request.Querystring("ID") and you'll know which document
you were working on in the previous step.
Submission System
Content Management Made Easy with ASP
Step 2 - Manipulation
|
