< form action = "destination_page" method ="post" or "get" >
Every website should have at least one "Contact Us" or "Feeback" form.
The primary reason for this, rather than a simple mailto: link is that well-designed forms will shield your E-Mail Address from spambots, crawlers and other e-mail harvesters. These automated tools scour every public file in your website or blog, looking for anything that looks like a valid E-Mail address.
Most hosting companies provide one or more forms processing scripts. The results, however, are usually a non-custom, unformatted E-Mail message, and generally less than ideal for anything other than simple notifications.
There are a few excellent template-based form processing scripts available, but these tools often lack the flexibility you need to make them do 'exactly' what you want, and many have a steep learning curve.
Forms based pages, however, can and will do much more than generate simple text-based E-Mail messages.
HTML Forms, in conjunction with one or more scripting languages, are being used to:
- Send custom HTML Mail
- Interact with databases to generate dynamic content
- Perform complex calculations
- Request information
- Place orders
- Generate Bar Codes
- Build membership systems
- Upload and download files
- Collect online payments
- Take reservations
- Conduct surveys
- Administer online tests and quizzes
- Build online contests
- Interact with Flash and other Web-based applications
- More … the limit is imagination.
Whether it's a simple request for information or a secure, multi-page survey connected to a database, you should maintain the same high quality design in your forms and their actions that you do for the rest of your sites.
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 needed. And 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.
When reduced to the most simple level,
the operation of an HTML form is
rather straight forward.
- 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. "Decoding" on the other end is usually automatic.
When to GET and When to POST
The encoded data stream is sent to its destination using one of two "Methods," GET and POST
Method 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.
For example, if you go to the Google™ home page and search for "giant snail" the Google™ home page will send you to ...
http://www.google.com/search?hl=en&source=hp&q=giant+brazilian+snails
The URL
(The Web Page Location)
The Query String Starts with the "?"
(Data being to the server by the form.)
The Query String (?hl=en&source=hp&q=giant+brazilian+snails) 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 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.
The GET Method In Action
Here's a simple <form> tag and some very basic input code.
<form name='theForm' action='page2.php' method="get">
<input type="text" name="textField" id="textField" />
<input type="submit" name="button" id="button" value="Submit" />
<input name="aHiddenField" type="hidden" value="Not Hidden At All" />
</form>
When the above form is submitted it will 'feed' the value of the Text Field using GET to page2.php That page will decode and show what you entered, and then return you here.
When you land on the simple results page, take note of the contents of the location bar. You can see why you wouldn't want to pass your credit card number or password in a GET variable. Even so-called "Hidden Input Fields" are passed in the Query String portion of the URL.
Method 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.
Use POST when you want to keep the form information out of sight while it is being transmitted. In fact, I recommend always using POST except in those cases where you want the form information to be visble, Google for example.
The POST Method in Action
Here's a simple <form> tag and some very basic input code
The only difference from the above Is GET Was Changed to POST.
<form name='theForm' action='page2.php' method="post">
<input type="text" name="textField" id="textField" />
<input type="submit" name="button" id="button" value="Submit" />
<input name="aHiddenField" type="hidden" value="Not Hidden At All" />
</form>
When this form is submitted it will 'feed' the value of the Text Field using POST to page2.php That page will decode and show what you entered, and then return you here. While on the page note how NONE ofg the form information is displayed in the Browswe Location Bar.
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.'
