- Understanding the HTTP Protocol
- Retrieving Data from the URL
- Sending Data with Hyperlinks
- Setting and Retrieving Cookies
- What You Have Learned
This chapter is from the book
This chapter is from the book
This chapter is from the book
Retrieving Data from the URL
At the end of the previous lesson, users filled out a short form and submitted it to a page that displayed the value they entered in the form. As you know from the preceding section, the variable sent from the form to the test_form_processor.asp page was enclosed in the body of the request. There are other ways to send data between pages. You can send variables through URLs, cookies, and (depending on your server technology) session and application variables. In other words, there are many ways to share data among pages.
The logical question that follows from this is, why are there so many different ways, and how do you know which one to use? The answer is that each has unique capabilities and limitations.
For example, the form variable you sent in Lesson 3 in the body of the request sent the data from the form page to the page that processed and displayed the information. One limitation of this approach is that once the server completes this transaction, it forgets the firstName name-value pair. So although it outputs the user’s first name to that page, if the user goes to a different page, the server no longer knows the value of the firstName variable, which means that this name-value pair is no longer available to your code.
In this task, you’ll pass data from the form to the test_form_processor.asp page in a different way: You’ll use a querystring. A querystring is a list of variables appended to the end of a URL. You have probably noticed as you surfed the Web that sometimes URLs are quite long and seem to contain much more information than the page address; that information is a querystring. Let’s modify the Web form you created in Lesson 3 so that it sends information using a querystring, rather than a form variable.
- Open test_form.asp.
At the moment the form is somewhat minimalist.
- In design view, position the insertion point anywhere inside the text First Name and click on <label> in the tag selector. Next set the Property inspector’s Format setting to Paragraph. Position the insertion point after the
text field, and press Enter/Return to create a new blank line. Insert a new text field, and in the accessibility dialog, label
it Last Name. With the new text field selected, use the Property inspector to name it lastName.
In this step, you are adding and formatting a second form field. Just because you are placing content in a form doesn’t mean you can’t format it as needed. You can insert just about any valid HTML element inside of a form.
- Click <form#frm_name> in the tag selector to select the whole form and also to bring up the form options in the Property inspector.
The easiest way to modify an element’s attributes—especially an element with several child elements, such as the <form> element—is to select it in the tag selector.
- In the Property inspector’s Method drop-down menu, select GET.
By default, the value is set to POST, which you left alone in the previous lesson. By changing the method from POST to GET, you are changing the way that the data is sent to test_form_processor.asp. With POST, the data is sent in the request body, as discussed before. But with GET, the data will be sent as a querystring, which means that the firstName and lastName name-value pairs are appended to the URL, as you will see in a moment.
- Save and close test_form.asp. Open test_form_processor.asp.
You need to modify the test_form_processor.asp page because the dynamic text on that page is looking for the firstName value to come to the page as a form variable. Now that you have changed POST to GET, the firstName value won’t be available as a form variable; it will be available only as a querystring. That means that you have to return to the Bindings panel and define a new binding.
- In the Bindings panel, for ASP click the New Binding (+) button, choose Request Variable, and in the Request Variable dialog
specify Request.Querystring as the type. Type firstName as the name. For ColdFusion and PHP, click the New Binding (+) button, choose URL variable, and enter firstName as the name. Click OK.
“Querystring” and “URL variable” are two variations of the same thing: a variable appended to the URL. There are some subtle differences between the way ASP and ColdFusion handle these types of variables, but for the purposes of this book, we’ll treat them as if they are no more than two different names for the same thing.
When you are finished, the change should be reflected in the Bindings panel. The screen shot is for ASP. ColdFusion and PHP users will see two categories of variable: Form (with firstName nested inside) and URL (with firstName nested inside).
- Repeat Step 6 to add a Request.Querystring/URL Variable for the lastName variable.
Again, the Bindings panel should update, and you should now see three variables defined: two versions of firstName and one of lastName.
It might seem odd to have the same variable—firstName—listed twice. But as far as ASP, ColdFusion, and PHP are concerned, these are two completely different variables. One is a form variable, and is only retrievable from the body of the HTTP request. The other is a querystring variable, which is only retrievable from the URL itself. This concept—where variables are available only in a designated place—is known as variable scope. A variable’s scope includes the place(s) where the variable exists, and excludes the places it does not. The lastName variable exists only as a URL querystring. If ASP, ColdFusion, or PHP looks for it in the request body, it won’t find it: The request body is outside of the querystring scope.
Scoping variables is a fundamental task in any programming language. Without it, you would have no way of ensuring that data is available when you need it and that two different pieces of data don’t inadvertently share the same name. It also speeds up processing as it helps the server narrow down its search for the variable, much like the zip code helps the post office narrow the search for your house.
By changing the form’s method from POST to GET, you change the firstName variable’s scope. By making these changes in the Bindings panel, you gave your server-side code access to the appropriate scope. There are many more scopes than form and querystring variables (as you doubtless noticed when working in the Bindings panel), but conceptually, they all work the same way.
- Click to select the blue-shaded {Form.firstName} dynamic text on the page, and then in the Bindings panel, select QueryString.firstName
(ASP) or URL > firstName (ColdFusion and PHP) in the Bindings panel, and click Insert.
When you are finished, you should see a new blue-shaded dynamic text block that contains {QueryString.firstName} (ASP) or {URL.firstName} (ColdFusion and PHP).
Now that you understand scope, you probably also can read Dreamweaver’s dynamic text pseudocode. The curly braces {} represent a dynamic code block, and inside is listed the scope, followed by a period, followed by a variable name. Dreamweaver pseudocode gives you quick access to the scope and name of all dynamic text.
Looking beyond the pseudocode at the real code, you should see <%= Request.QueryString("firstName") %> embedded in the HTML on the ASP page, <cfoutput>#URL.firstName#</cfoutput> on the ColdFusion page, and <?php echo $_GET['firstName']; ?> on the PHP page.
- Position the insertion point after the firstName block, insert a blank space, and bind the QueryString.lastName or URL.lastName
variable to the page by selecting it in the Bindings panel and clicking Insert.
The two variables should appear side by side, so that the output displays the user’s entire name.
- Save test_form_processor.asp, and in the Site panel, Shift-select test_form.asp and test_form_processor.asp and click the
Put File(s) button.
Remember, you can’t test your files unless you upload them to the server.
- Click test_form.asp in the Site panel, and press F12 to test in a browser. Enter your first name and your last name, and click
Submit.
As you’ve anticipated, the page now thanks you using your first and last name.
Of more interest, though, is the URL. Appended to the page address is a question mark followed by three name-value pairs:
http://localhost/newland/test_form_processor.asp?firstName=Ghengis&lastName= Kahn&button=Submit
The appended three variables are the querystring. The output first and last names are pulled directly out of the URL. This URL appears the same, regardless of server model, because querystrings are a part of HTTP itself, rather than a dynamic Web page technology.
Generally, you should use POST, rather than GET, to send form data to be stored in a database, because with POST the data is not visible to the user. Also, you can embed quite a bit more data in the request body using POST than you could in a URL using GET. But for the sake of this exercise, GET is sufficient. As you will see momentarily, though, querystrings have some advantages that form variables don’t.
- Close your browser. In Dreamweaver’s Site panel, click test_form_processor.asp, and press F12.
)
)
)
)
)
)
)
)
This time, when you test the page, it lacks the querystring data that ASP, ColdFusion and PHP are expecting, because you closed the browser and flushed that data from memory. Interestingly, ASP and PHP handle this problem differently than ColdFusion. ASP and PHP display, “Thank you, , for filling out my form.” ColdFusion only gets as far as “Thank you, “before giving an error message stating that “Element FIRSTNAME is undefined in URL.” It was expecting your firstName variable in the URL scope and did not find it.
One of the challenges of dynamic site development is to make sure that no user enters a page without all of the data that the page needs to process. If this happens, the result is often an error that confuses and frustrates users. The solution to this problem is twofold: Prevent users from accessing pages without sufficient data in the first place, and if that fails, catch the error and redirect users to an all-purpose error page that enables them to notify the Webmaster, which is better than them seeing a cryptic ASP, ColdFusion, or PHP error message. We’ll use several different types of validation during the course of this book to prevent users from accessing pages without the required data.
