Web Form Submission by Seth Willits 09-25-04 Printer Version

GET/POST Forms
There are two types of requests that pretty much drive the internet. There's a GET and a POST. If you ever been to a website and submitted a search form and saw all sorts of stuff after a question mark in the URL (ie, Google's website does this), that's a GET form. Unlike a GET form where the parameters for the request are part of the URL string, POST forms submit additional parameters (other than the URL itself) in a way that is hidden from the user. POST forms are usually used for forms that contain sensitive user information, or information the site doesn't want you to see (like field names or something). REALbasic offers a way to submit form data for either GET or POST forms (the only difference is the method name you call), and it's A LOT easier to do it now with an HTTPSocket than it was using a regular TCP Socket years ago.

The URL we'll send the request to is in the action attribute. Now remember, this is a URL relative to the site you're working on, so in this case it would be "http://www.realsoftware.com/listarchives/cgi-bin/namazu.cgi". The type of form is in the method attribute (GET).

The field names are the in the "name" attributes of the various fields in the form. While the field values are either explicitly or implicitly the "value" attribute. By that, I mean if the field is a text field, a "value" isn't initially supplied, so you won't find a value attribute in the html. In the case of the search field we have: <input type="text" name="query" size="40">

This shows that the field name for the search field is "query", and the value will be determined by the user, unlike the description popup, where the values for the choices are given:

<select name="result">
   <option selected value="normal">normal</option>
   <option value="short">short</option>
</select>

In this case, if the name of the field is "result" (and odd name, but that's what it is) and the value will either be "normal" or "short" depending on which option is selected.

The Design
So, I'll skip going through the rest of the html and we'll move straight into the example. Below is an image of the layout of the window. There's a search field named EFQuery, a button named BtnSearch, four popups named PopDisplay, PopDescription, PopSort, and PopList, a progress bar named ProgressBar1, a giant result field (which will contain the html of the result page) named EFResult, and an HTTPSocket instance named HTTPSocket1.

The BtnSearch Action Event
Next, the general idea is to have the user fill everything out in the interface and click the search button. A dictionary instance is then created with the field name/value pairs as you can see below. The first value specified (submit/Search!) is the search button. Yes, buttons are considered fields too. Often, there are times where two or three buttons are in a form and you need to know which one was clicked. In this case there is only one button, so theoretically the page wouldn't need to know which button was clicked, but you never know, so stick it in anyway.

After building the dictionary, you then fire off the request to the HTTPSocket, specifying the Action parameter of the form as the URL, followed by a question mark (?) which basically says "there is form data after the url", and then the form data itself. Rather than having to write the form data in a url encoded format (?submit=Search&query=blah+blah+blah&idxname=.....) you simply use the EncodeFormData method which returns the dictionary in that format for you. Very handy!

The HTTPSocket
After that we have to handle whatever happens in the HTTPSocket. If an error occurs with the socket (could not connect to the server, violently disconnected, or something), we handle it in the Error event.

If an error happens on the server, we have to handle that in the PageReceived event (or the DownloadComplete event if we had specified a folderitem to download to in the Get method). The server will send back a status message along with whatever result comes back. The "OK" status message (everything went as planned) is "200". There is a list of all status messages on the w3 website.

The content parameter contains the html of the resulting page, and we simply display that in the EFResults field.