Submitting the Form

We're halfway done allowing users to add new pages to our wiki. 0:00 We've created an HTML form that browsers can retrieve using HTTP GET request. 0:03 The problem now is that when the completed form is submitted, 0:09 the browser sends a second request that we're not prepared to handle. 0:12 We need to set up our app to accept this second request and 0:16 save the form data to the server. 0:18 When we submit the form for a new page, 0:21 notice that the form fields are being encoded and added onto the URL. 0:23 That's because our form is being submitted using a GET request. 0:27 Using an HTTP GET request is fine when you're getting data from the server, 0:32 when you type in a URL or click a link, you're just getting a new page, so 0:36 your browser sends a GET request. 0:40 It's even fine to use GET requests for 0:42 simple search forms on a website, because you're still just retrieving data. 0:44 That's why browsers use GET requests by default when submitting an HTML form. 0:48 But when you're adding new data to a server that will be accessible at 0:54 a new path, you're supposed to use an HTTP POST request instead of a GET request. 0:57 There are various technical reasons for this, 1:03 which you can read more about in the teacher's notes if you want. 1:05 But there's one very visible benefit to switching to POST request right now, and 1:08 it's that form parameters are submitted in the request body 1:12 rather than encoded in the URL. 1:15 That means no long ugly URLs when we submit the form. 1:17 So let's go back into our new.erb template. 1:22 We're gonna edit the age female form to submit via POST instead. 1:25 We do this by adding a method attribute to the form element, and 1:32 we're gonna give it a value of post. 1:38 And just as GET request need a particular path on the server to retrieve, 1:41 POST request need a particular path to send their data to. 1:45 Whereas the path for GET request is specified the using the URL, the path for 1:49 POST request is specified in the form HTML. 1:53 To set that up we'll need an action attribute. 1:56 To set that up we'll need an action attribute. 2:00 Because we're creating a new wiki page. 2:07 Let's save that, reload or preview. 2:10 Fill in our form, And click Submit. 2:14 Our browser goes to the /create path. 2:20 And you can see there's no encoded form parameters in the URL. 2:22 But we also see the error, Sinatra doesn't know this ditty. 2:26 That's because we haven't set up a Sinatra route that can handle this type of 2:29 request yet. 2:33 We'll take care of that in a bit. 2:33 We can confirm or 2:35 sending a POST request now by using our browser's developer tools. 2:37 Let me go back to the new page form here. 2:40 Then I'll open developer tools. 2:43 Expand that a bit, and click on the Network tab. 2:46 Down here it says Recording network activity. 2:50 Perform a request. 2:53 So I'll resubmit the form to perform the POST request. 2:54 We can see the request down here at the bottom. 2:59 The server still failed to respond, which is why it's highlighted in red. 3:02 But you can see that the method is POST. 3:05 If we click on the request, we can view its details. 3:08 We can scroll down to Request Headers and click View Source, and 3:11 we'll see that it did indeed send a POST request for the create path. 3:17 We can also scroll down to the bottom to view the Form Data that was submitted. 3:21 There's our title field and a content field. 3:25 So now our browser is sending POST requests with the form data. 3:29 Our next step is to set up our Sinatra app to actually process that data. 3:32 We'll look at that next. 3:36