Query Strings and Form Variables


Query Strings and Form Variables

Almost all input from a Web application that you build with ATL Server will be taken from query strings and/or form variables. In this section we discuss the differences between query strings and form variables. If you re already familiar with these concepts, feel free to skip to the next section, where we explain how ATL Server handles this data.

The input for a Web application is categorized as being all the values of the HTML tags that are inside a form (between the < form > < /form > tags) and have a name attribute specified. Consider the following example:

 <input name="input1">Not part of input  <form>    <input  name="input2"  >Hello    <text area  name="input3"  >World!</textarea>    <input name>Not part of input  </form> 

In this example, only the values Hello and World ! are considered as input values for this hypothetical Web application because they re the only elements that are both inside the form and have name attributes. This data is sent as follows :

 input2="Hello"&input3="World!" 

This data can be sent as a query string or as form variables. Query strings send the data appended to the URL of the request (very common in search engines), whereas form variables send the data by adding it as content to the HTTP request back that s sent to the server. The only difference between the two techniques is how the information is returned to your server, and you choose between the two by specifying the METHOD attribute in your form tag. If the METHOD attribute is specified as POST , then your data will be sent as form variables. If the METHOD attribute is GET , then your data will be sent as a query string. Consider the example in Listing 6-1.

Listing 6.1: Source for a Simple Server Response File (SRF)
start example
 {{handler userinput.dll/Default}}  <html>    <body>      <form  method="post"  >      <table border=1>      <tr>      <td colspan=2>        Welcome to Ben's World of Fruit.      </td>      </tr>      <tr>      <td>Please select an item:</td>      <td>        <ul>        <li><input type="radio" name="fruit" value="apple" ID="Radio1">Apple        <li><input type="radio" name="fruit" value="peach" ID="Radio2">Peach        <li><input type="radio" name="fruit" value="orange" ID="Radio3">Orange        </ul>      </td>      </tr>      <tr>      <td>Type:</td>      <td>        <input type="radio" value=1 name="organic">Organic        <input type="radio" value=0 name="organic">Conventional      </td>      </tr>      <tr>      <td>Quantity:</td>      <td><input name="quantity"></td>      </tr>      <tr>      <td colspan=2>        <input type="submit" value="Go">      </td>      </tr>      </table>      </form>    </body>  </html> 
end example
 

Because this example uses POST as the METHOD , the data will be sent as form variables. Using some hypothetical input as an example, the HTTP request sent to the server when this form is submitted would look like this:

 POST /wof/bensworldoffruit.srf   . (other HTTP headers omitted for brevity)  Content-Length:33  Fruit=apple&organic=1&quantity=1 

If we had used GET , the input would be a query string, and our request would look like this:

 GET /wof/bensworldoffruit.srf? Fruit=apple&organic=1&quantity=1 

The main reason to choose POST over GET is that there are limitations on how long your query string can be. This limitation isn t standard between browsers. In practice, the limit of a GET request is roughly 1,000 characters . But, the main reason to choose GET over POST is that GET allows you to build a canned query for your Web application, for example:

 <a href= "/BensWorldOfFruit.srf?fruit=apple&organic=1&quantity=1>  Click here to buy an organic apple!<a/> 

When your user clicks this link, the request will be sent as a query string to your ATL Server application as though the user had filled out the form and clicked Submit. We use this form as the basis for the rest of the examples in this chapter.

ISAPI developers will fondly remember having to handle and parse GET and POST requests themselves . This process was both tedious and error-prone . ATL Server provides a framework that handles most of this type of work for you.




ATL Server. High Performance C++ on. NET
Observing the User Experience: A Practitioners Guide to User Research
ISBN: B006Z372QQ
EAN: 2147483647
Year: 2002
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net