Uploading myNews Files: From the Browser to the Server
So far, although we've used some new approaches, we really haven't seen anything new from a technical standpoint.
When we set up the News section of mySpace, we had planned to simply link to files that were on the server instead of storing entire news articles in the database. That's great for the database, but it means that to maintain this section, we're going to have to be able to upload files to the server and remove them when we're done with them.
GEEK SPEAK: Upload means to move something from your computer to another computer. This is the opposite of downloading, which is to take something from another computer and put it on your own.
Uploading files isn't something that's included in ASP as a matter of course, but there are numerous components out there that we can use to help us out. As you may remember, there was even a trial version of one installed with ASPEmail, ASPUpload. We're going to use that to take a look at some of the issues involved with uploading files to our site.
The basic process is the same as it was for editing the links table, so let's start by making a copy of those pages. Copy edit_links.asp, edit_links_action.asp, edit_links_rec.asp, and edit_links_rec_action.asp to edit_news.asp, edit_news_action.asp, edit_news_rec.asp, and edit_links_rec_action.asp, respectively.
Let's start with edit_news.asp (see Listing 8.12).
Code Listing 8.12. edit_news.asp: Selecting news items to delete
For the most part, we just replaced the words link and links with news, but also we've added a slight enhancement (see Figure 8.3). Part of the news item is it's category, so we'll need a way for our administrator to set that. But rather than expect our administrator to remember every category ID, we're pulling the name from the news_categories table and displaying that. Additionaly, because we're not changing anything in the database—we're just reading it—we're setting the RecordSets to use Read Only locking. In other words, they don't have to lock anything at all.
Now you see part of the advantage of being as generic as we can. If we'd specifically listed the columns in the links table, we'd have to rewrite this whole page! Let's move on to edit_news_action.asp (see Listing 8.13).
Figure 8.3. With just a few simple modifications to edit_links.asp, we can display our edit page for news.
Code Listing 8.13. edit_news_action.asp: Changing/adding news items
In this case, literally all we did was change link and links to news. Again, being generic definitely has its advantages.
Now let's move on to edit_news_rec.asp (see Listing 8.14), where we start to get into the big changes.
Code Listing 8.14. edit_news_rec.asp: Adding the file upload box
In this case, we did hard-code the field names, so we'll have to change the names to match the news table. We also needed to add a field for the category ID, which didn't exist in the links table. We're doing all of that on lines 25 through 36.
On lines 56 through 71 we added a line to the form for our news category, checking to make sure that the current category for the item is marked as selected. Again, we didn't want to just display a category ID—or even worse, expect our administrator to type it in—so we're creating a pull-down menu.
The only thing new here is the way that we've implemented this. Normally, when we've been putting dynamic data into form elements, we've been doing it with the <%= %> syntax. This was because we wouldn't have to worry about how to print a double quote to the page. After all, if we tried
Response.Write ""Hello!""
ASP wouldn't know what to do with it. It would hit the second quote and think the line was finished, so it would consider everything from the "H" to the last quote an error. When we had single quotes in SQL, we could put two of them together and the database knew what to do with it. Not so for double quotes and VBScript.
Instead, what we did this time on line 62 was to use Response.Write, but for each double quote we've told ASP to print out character number 34. Every character you can type (and lots that you can't) has a number, called an ASCII code. It just so happens that the ASCII code for a double quote is 34. So if catSet(cat_id) was 5, the code
Response.Write "<option VALUE="&chr(34)&catSet("cat_id")&chr(34)&>
is going to print out
<option VALUE="5">
None of this has been too much of a change from editing the links table, but now we're getting into something new. On line 89, we've put in a new kind of form element, a file element. This tells the browser to display not only a box for the name of the file, but a Browse button that will let us designate a file to upload (see Figure 8.4).
Figure 8.4. The file element tells the browser to let us browse our computer for a file to upload.
But the file element won't do us any good unless the browser also knows it should send the whole file, and not just the name. We tell it to do so by adding an encoding type to the form tag on lines 42 and 43.
enctype="multipart/form-data"
is required if we're going to be uploading files.
Those were substantial changes, but they're nothing compared to what we're going to do with edit_news_rec_action.asp. That's where we're actually going to take in that file and do something with it. Open edit_news_rec_action.asp and add the changes in Listing 8.15.
Note
If you didn't register and install the ASPUpload component back in Chapter 6, "Adding Person-To-Person Auction Capabilities," go back and do it now.
Code Listing 8.15. edit_news_rec_action.asp: Saving the uploaded file
Except for changing the names and accommodating the news_cat_id field, we really only added three lines to this page, but they make all the difference in the world.
On line 8, we're creating an instance of the Upload object, the third-party component that will handle the information we've told the browser to send. Line 9 is where we're actually doing the work, asking it to Save. Until we do that, we won't be able to get at any of the information, including the file.
When we tell the Upload object to Save, it looks through all of the content and headers that were sent to the server and picks out the files and the rest of the form data. We could even, if we wanted, send multiple files at one time by creating more than one file element to our form. The Upload object will then save them in whatever directory we've specified on line 9.
It would seem that that was all we had to do, but that's not quite true. Because of the encoding we used—multipart-formdata—the rest of our form elements aren't available to the normal Request.form object. Fortunately, the Upload object takes care of that, basically replacing Request.form with Upload.form, so we can still get at our data.
Finally, on line 18, we destroy the Upload object. We've saved the data from it, so we can destroy it and and save our data to the database as usual.
Here's a question, though: If Upload saves the file with it's original name (which it will) and also enables us to retrieve that name (which it does, using Upload.files().path), why did we bother to include a field for our administrator to enter a filename? Wouldn't it just make more sense for them to upload it directly to it's final location and be done with it?
The answer is a definite sometimes. If we were to go that route, the file would have to be completely prepared, including headers and footers, before it was uploaded. There's nothing wrong with that if we have a low volume of material and an administrator with time to spare. Of course, we'd never be able to use that file in any other way, say, as a compilation of some sort.
But what if we could upload a plain text file and have the server do the rest of the work for us? That's what we'll talk about next.