While basic HTML forms that send simple, unformatted, plain text E-Mail are relatively easy to implement, getting beyond the basics can be a confusing path for new and experienced designers alike.
Mastery of HTML forms requires a client side scripting language, usually JavaScript, a server side scripting language such as PERL, Python or the popular PHP. If database interaction is needed, a knowldege of SQL or other appropriate RDBMS is required.
Obviously the server hosting the site must support the chosen development languages.
That being said, the top-level operation of an HTML form is rather straightforward.
- Display the HTML Form to the Visitor
- The visitor fills in the information and clicks the "Submit" button.
- If required, preliminary error checking is performed by the browser. (client)
- The form then takes the information that the visitor enters and "sends" it as a data stream to the web page or script defined in the "action" attribute of the <form> tag, using one of two methods, GET or POST.
- Additional error checking may also be performed by the Web server and the form 'returned' to the client for corrections before final processing.
Before the form information is sent, it is automatically encoded into a 'standard' format so that the receiving web page, script or program will know how to deal with it. The kind of encodong used depends on the nature of the information being sent, text, html, graphic, etc.
The encoded data stream is sent to its destination using one of two "Methods."
|
a) |
GET |
When the GET method is used, the form information is 'tacked on' to the end of a URL and made a part of the "Query String" that you see at the end of many searches.
As an example, if you go to the Google™ home page and search for "giant brazilian snails" the Google™ home page will send you to ...
http://www.google.com/search?hl=en&source=hp&q=giant+brazilian+snails&cad=h
http://www.google.com/search |
?hl=en&source=hp&q=giant+brazilian+snails&cad=h |
The URL of the Destination
Page or Script |
The Query String
(Data being to the server by the form when submitted.) |
?hl=en&source=hp&q=giant+brazilian+snails&cad=h contains a few codes put there by the Google™ folks as instructions, but your form input is right there in the location bar for you and the whole world to see, copy and paste.
This is very handy for things such as search queries, catalog items and similar Web pages. It's not, however, private. The GET method is not good for form information that might be considered sensitive, and is succeptible to hijacking. You would never transmit a credit card number or password using GET, for example.
BTW, the substitution of plus signs "+" for spaces is part of the URL encoding. The script on the other end knows how to decode it. |
|
b) |
POST |
The POST method of form information delivery also encodes the form information, but instead of sticking it on the end of the URL for the world to see, the information is delivered in an 'embedded' data stream and will not be seen by the visitor. |
Where the information from the form actually goes, or what it does when submitted is controlled by the "ACTION" section of the <form> tag.
The information can be sent back to the same page, to another Web Page or to a Server Side Script for further processing such as generating an E-Mail or updating a database.
|
Conclusion: If you want someone to be able to copy and paste the URL and all data transmitted by the form, and if the total length of the URL with all query strings would be fewer than 255 characters, GET should be used.
If, however, you do not want the query string exposed to view, or if the query string is more than 255 characters, you should use post.
You should generally use POST as your preferred method, unless GET is required. If nothing else, it's 'neater.' |
