Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
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 upYou need to sign up for Treehouse in order to set up Workspace
Sign up