Understanding HTML Forms Processing
The most difficult thing to understand about HTML forms processing is “what happens where.” When a visitor views a Web page that does not contain a form, the server simply responds to the browser’s requests for the Web page and the individual items the page contains, such as graphics and animations. For example, when someone “visits” a Web site, the visitor’s browser requests a Web page from the Web server. After the server returns the HTML page, the browser examines the
HTML statements and begins to display the page. When the browser encounters tags that require more data from the server, such as an <img> tag that specifies a graphic, the browser requests the server to send the corresponding file. The server and browser continue this “request/ response” interaction until the browser has retrieved all the files the browser needs to display the Web page content.
After the Web server sends the HTML document (including any referenced graphics images, animations, sound files, or video clips as requested by the Web browser), the Web server’s job is done. It is up to the Web browser to display the Web page text and graphics and to play back any sound files or movie clips available on the page. When the visitor clicks one of hyperlinks on the Web page, the browser sends another request for a Web page to the Web server, which, in turn, sends the requested document (and support files as the files are requested) to the Web browser for the browser to process and display.
When working with a Web page that contains a form, the browser and server perform the previous two-way conversation to download the page and its contents (which includes the form). After the visitor fills in the form’s entries and clicks Submit, the browser sends the form results back to the server, which must then process the results in some way. Normally, the server will process the form results by running a specific script. Depending on the script’s purpose, the script, for example, might place the user’s data into a database, might use the information to start an e-commerce transaction, or, in the case of a form at a search-engine site such as Yahoo, use the form’s contents to search the server database for a list of related links. As you will learn later, within the HTML entries that create the form, the designer specifies the program the server runs after the visitor submits the form results.
Normally, behind the scenes, when the visitor clicks Submit, the browser will run a script that resides within the same HTML file as the form. The script verifies that the visitor filled out the form completely and may check the “correctness” of some of the responses. Then, the browser will package up the information and send it to the Web server, telling the server the name of the application the server should run to process the form results.
In summary, after the Web server sends the Web page with the form to the Web browser, the server goes on about its business—as the server does after sending any other Web page (with or without forms) to a Web browser. The Web browser takes care of accepting the visitor’s input into the form’s text fields and mouse click selections on the form’s radio buttons, check boxes, and selection lists. When the visitor has finished filling out the form, the Web browser must again communicate with the Web server to send the information entered on the form to the Web server for processing. The Web server, in turn, runs a specific script to process the form results and sends a message to the Web browser confirming the receipt of form results and often the success or failure of form data processing.