A Route for PUT Requests6:43 with Jay McGavren
POST requests are intended for brand new resources that you haven't assigned a path to. But this time we're modifying an existing resource on the server, one we have already assigned a path for (a slash followed by the page title). When you're modifying an existing resource with a known URL, it's recommended to use a PUT request, not a POST request.
To let users create new Wiki pages we needed two Sinatra routes. 0:00 First, the get route that let their browser retrieve a blank HTML form. 0:04 Second, a post route that accepted the form data and saved it on the server. 0:08 We implemented both of those in the previous stage. 0:13 To let users edit existing wiki pages, we need two more Sinatra routes. 0:15 First, a get route that lets a browser retrieve an HTML form that's prepopulated 0:21 with the existing pages data and second, a route that accepts the form data and 0:25 saves it on the server. 0:30 But ideally we would not use a post request for this. 0:32 Post requests are intended for 0:35 brand new resources that you haven't assigned a path to on the server. 0:36 But this time we're modifying an existing resource on the server, 0:41 one we have already assigned a path for, a slash followed by the page title. 0:44 When you're modifying an existing resource with a known URL, 0:49 it's recommended to use a put request, not a post request. 0:53 See the teacher's notes if you'd like the technical details on this. 0:56 So, it would be better to use a put request to submit this form. 1:01 But how do we do that? 1:04 Let's try a web search for the HTML form elements method attribute. 1:06 HTML, form method. 1:10 We'll search for the method attribute in the documentation method. 1:18 It looks like the only answer you values that browser support are post and get. 1:24 So it looks like we have no choice but 1:29 to set the method attribute of our form element to post. 1:31 But Sinatra can support put requests in spite of this limitation. 1:38 It's been programmed to look for 1:42 an additional parameter in form data, named _method. 1:43 The underscore is to prevent conflicts in case you have an actual form 1:47 field named method. 1:50 If it sees an underscore method parameter, and its value is put, 1:52 then Sinatra will treat the post request as if it was a put request. 1:55 But how do we add the parameter to our form data? 2:00 We don't want to add another text field, that would be ugly and confusing to users. 2:03 That's why HTML forms offer another input type, hidden. 2:07 We can just add an input tag, set its type attribute to hidden, 2:12 we can assign the hidden input a name of _method, and a value of put. 2:17 That way an underscore method parameter will be included with the other 2:28 form parameters but your users will never see it. 2:31 Well, not unless they inspect the HTML source of the form, anyway. 2:34 Just as with post requests, 2:39 we need to specify what path put requests should go to. 2:40 Ideally, this will be the path of the resource we're modifying, 2:44 which is a slash followed by the page title. 2:46 So we'll add an action attribute that will specify the path. 2:48 It needs to start with a slash and then we'll use an erb 2:56 output tag to embed the title in the attribute. 3:02 Save that when we're done. 3:12 And now if we restart our server. 3:15 Reload the edit form and click submit. 3:20 We'll see the usual Sinatra doesn't know this ditty error, 3:22 because there's no matching route. 3:27 But if we open our browser's developer tools, wwitch 3:29 to the Network tab and then hit the back button and submit the form again. 3:34 We'll see that as far as the browser is concerned, we're sending a post request 3:40 but if we click on that request and scroll to the form data at the bottom, 3:44 we'll see an underscore method parameter with a value of put. 3:47 Also, if we close out of developer tools and 3:51 look at the bottom of the page, we'll see that Sinatra is recommending we create 3:54 a route to match this request using a method named put. 3:57 Our form submission is being treated as a put request. 4:01 So let's create that route. 4:05 We'll go into our app code. 4:06 And, just as the get method from Sinatra creates a route for get requests and 4:14 the post method creates a route for 4:17 posts requests, the put method creates a route for post requests. 4:19 It works the same way as the other methods. 4:24 You pass it a string with the request path to match, and 4:26 a block to be invoked when the matching request has received. 4:30 We've set our form submission path up to consist of a slash followed by the title 4:33 of the page we're updating, so 4:37 we'll use a slash followed by a title URL parameter as path for this route. 4:39 Within the block, we'll call save content to save or 4:48 update a page content to a file. 4:51 The title parameter from the request path will be our first argument 4:54 used to determine the name of the text file to update. 4:58 The content parameter from the form's text area will be our second argument 5:03 that will get saved as the files contents. 5:07 And just like in the route to create a new page, we'll want to send a redirect 5:13 response to the browser so that it sends a get request to view the updated page. 5:16 So redirect. 5:20 And we'll interpolate in the value of the title parameter. 5:23 We also mustn't forget to call URI escape on the path to encode any invalid 5:31 characters URI. 5:35 Escape. 5:37 And we'll just pass at the path as it is. 5:41 Since we're able to use the save content method both to create new files and 5:43 update existing files, the block to update the page 5:47 looks pretty much identical to the block for creating a page. 5:50 The only difference is that the title parameter comes from the request 5:55 path instead of the form data. 5:58 Let's restart our server. 6:00 And then we'll try editing a page again. 6:05 We'll make a simple edit. 6:07 And click the Submit button and we'll see that our changes are saved and 6:13 we're redirected to view the updated page. 6:16 If we go into the pages directory in our workspace and 6:19 open the text file, we'll see the changes reflected there as well. 6:22 Our users can update existing Wiki pages now. 6:26 There's one more thing users can't do. 6:30 They can't delete pages they don't want anymore. 6:32 In the final stage, we ll fix that. 6:34 We'll also show you how to serve up a CSS stylesheet to make the site 6:36 look much better. 6:40 See you in the last stage. 6:41
You need to sign up for Treehouse in order to download course files.Sign up