Well here's a list of files we ended up with when version 1 first appeared:
forum.mdb - the Access database used to store the forums and messages
(6 miscellaneous small icons) - images to make it more user friendly
common.asp - all our constants and functions which are needed on multiple pages
display_forum.asp - diplays the forum list as well as the messages in the open forum
display_message.asp - shows the selected message details and body
post_message.asp - the form and processing for posting a message rolled into one
I guess the next step is to do a quick overview of each page and how they all fit together.
I'll start with the database.
The format for our database basically came directly out of looking at the databases running the other forums we were considering and taking the parts we liked from each and discarding the rest.
The forum table is pretty straight forward.
Each forum has an id, a name, and a description.
The message table gets a little bit more complex, but not too bad.
Naturally we need a unique message id so we know what message we're talking about.
We also need to know what forum the message belongs in so we added forum_id.
Now we get to the fields that need some explanation.
Like I said earlier, we wanted a threaded forum so.... we need to maintain thread information.
The thread_id is the message_id of the root message of the branch the message belongs in.
If the message happens to be the first post in a new thread (a root message) then this is set to the value of it's own message_id.
Then all responses to it, responses to those responses, etc. get assigned this message's id as their thread_id.
So all messages in the same thread have the same thread_id which is equal to the message_id of the root message.
(It's really not that bad once you see it in action.
I'll address threads again in the explanation of the code.)
A message's thread_parent is the id of the message it's a reply to.
(ie. the message right above it in the tree)
If it's a root message, this is set to zero.
The final thread field is thread_level.
To tell the truth, it's not needed at all for the forum to operate.
We added it so that at a quick glance into the database, we could see how deep a message was in a thread.
If this field wasn't here you'd have to look for it's parent, and then it's parent's parent and so on until we got to a root post counting the number of levels along the way.
The final five fields are again pretty self explanatory.
We've got the author's name and e-mail address, the time and date the message was posted, the subject of the message, and finally the message body.
The common.asp file is actually not really an .asp file at all.
It's actually an include file that we include into each of our script pages.
We use the .asp extension as opposed to the traditional .inc so that if someone happens to call it from a browser, they'll simply get a "document contains no data" error and not be shown the source code to our forum.
(Actually we just like the pretty color coding that Inderdev does on our .asp files, but we thought you'd probably want a better reason than that!)
It's in this file that we place all our constants and any functions that are used in more than one script.
This allows us to share them and reduces duplicate code.
First of all you'll see the database connection constants.
These include a connection string, username, and password and are used whenever we need them in the script.
Then we have some selected constants pulled directly from the adovbs.inc file.
You could simple include the whole file (yes, you can do nested includes) but, since we only use about 8 of them that seemed like a little bit of over kill.
The remainder of the file is made up of functions.
There are basically three types of functions in the file.
The first type are little helper functions like Lineify which simply append our carriage returns or perform similar little menial tasks which help to make our coding easier.
The second group consists of our database functions.
These include OpenDataConn and CloseDataConn which manage our data connections, GetRecordSet which creates a recordset, connects to the database, and then returns the recordset to the calling script, GetCount which gets a count of items in the database matching your request, and InsertRecord which is included here only to try and keep our database functions all in one place (It's only called once and could very well have been placed in the post_message page).
The final set of functions all start with the prefix Show.
These basically take some data as an input and format it before outputting the HTML and passing it out to the browser.
These include ShowHead, ShowTail, ShowForumLine, ShowMessageLine, and ShowSearchForm.
Using these functions for our output not only allows us a great deal of consistency throughout the forum, but makes changing the way something displays much simpler since we can change it in one place and have the changes be immediatly used throughout the forum.
The first page people hit when they go to the forum is display_forum.asp.
It simply queries the database and displays a list of the available forums and the number of messages in each.
The user can then choose a forum by clicking on it.
This once again calls display_forum.asp but this time passes it the parameter fid (short for forum id) whose value matches the forum they want to see.
The script then displays the forums again, but this time, when it reaches the one they want to open, it retrieves all the root level messages in that forum and displays the subjects hyperlinked to the show_message.asp page.
The other thing that happens when display_forum is passed a forum id is that the "post a new message to this forum" link is enabled so users can post new root level messages to the open forum.
This brings us to display_message.asp.
It has the simplest job of the scripts.
It takes the parameter mid (short for message id), queries the database for the appropriate record, formats the message, and displays it.
For the reader's convienince, it also shows some thread information such as replies to the current message and the message that the current one was posted as a reply to.
It's only other job is to call post_message.asp with the appropriate parameters if the reader wants to post a reply.
Finally we reach post_message.asp.
This is the only way new messages get added to the forum.
The script actually does double duty in that it not only diplays the form to be filled out, it also acts as the processing page.
This design allows us the flexability to simply show the form again with the users previously entered input if anything is wrong with it or if errors occur during the update.
Another small duty that post_message.asp performs is storing the users information if they want so they don't need to enter it every time they want to post.
As written, it simply sets a cookie, but this could easily be changed to store it in a user table if that's required or would be more useful.