To let users create new Wiki pages we needed two Sinatra routes.

First, the get route that let their browser retrieve a blank HTML form.

Second, a post route that accepted the form data and saved it on the server.

We implemented both of those in the previous stage.

To let users edit existing wiki pages, we need two more Sinatra routes.

First, a get route that lets a browser retrieve an HTML form that's prepopulated

with the existing pages data and second, a route that accepts the form data and

saves it on the server.

But ideally we would not use a post request for this.

Post requests are intended for

brand new resources that you haven't assigned a path to on the server.

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.

See the teacher's notes if you'd like the technical details on this.

So, it would be better to use a put request to submit this form.

But how do we do that?

Let's try a web search for the HTML form elements method attribute.

HTML, form method.

We'll search for the method attribute in the documentation method.

It looks like the only answer you values that browser support are post and get.

So it looks like we have no choice but

to set the method attribute of our form element to post.

But Sinatra can support put requests in spite of this limitation.

It's been programmed to look for

an additional parameter in form data, named _method.

The underscore is to prevent conflicts in case you have an actual form

field named method.

If it sees an underscore method parameter, and its value is put,

then Sinatra will treat the post request as if it was a put request.

But how do we add the parameter to our form data?

We don't want to add another text field, that would be ugly and confusing to users.

That's why HTML forms offer another input type, hidden.

We can just add an input tag, set its type attribute to hidden,

we can assign the hidden input a name of _method, and a value of put.

That way an underscore method parameter will be included with the other

form parameters but your users will never see it.

Well, not unless they inspect the HTML source of the form, anyway.

Just as with post requests,

we need to specify what path put requests should go to.

Ideally, this will be the path of the resource we're modifying,

which is a slash followed by the page title.

So we'll add an action attribute that will specify the path.

It needs to start with a slash and then we'll use an erb

output tag to embed the title in the attribute.

Save that when we're done.

And now if we restart our server.

Reload the edit form and click submit.

We'll see the usual Sinatra doesn't know this ditty error,

because there's no matching route.

But if we open our browser's developer tools, wwitch

to the Network tab and then hit the back button and submit the form again.

We'll see that as far as the browser is concerned, we're sending a post request

but if we click on that request and scroll to the form data at the bottom,

we'll see an underscore method parameter with a value of put.

Also, if we close out of developer tools and

look at the bottom of the page, we'll see that Sinatra is recommending we create

a route to match this request using a method named put.

Our form submission is being treated as a put request.

So let's create that route.

We'll go into our app code.

And, just as the get method from Sinatra creates a route for get requests and

the post method creates a route for

posts requests, the put method creates a route for post requests.

It works the same way as the other methods.

You pass it a string with the request path to match, and

a block to be invoked when the matching request has received.

We've set our form submission path up to consist of a slash followed by the title

of the page we're updating, so

we'll use a slash followed by a title URL parameter as path for this route.

Within the block, we'll call save content to save or

update a page content to a file.

The title parameter from the request path will be our first argument

used to determine the name of the text file to update.

The content parameter from the form's text area will be our second argument

that will get saved as the files contents.

And just like in the route to create a new page, we'll want to send a redirect

response to the browser so that it sends a get request to view the updated page.

So redirect.

And we'll interpolate in the value of the title parameter.

We also mustn't forget to call URI escape on the path to encode any invalid

characters URI.

Escape.

And we'll just pass at the path as it is.

Since we're able to use the save content method both to create new files and

update existing files, the block to update the page

looks pretty much identical to the block for creating a page.

The only difference is that the title parameter comes from the request

path instead of the form data.

Let's restart our server.

And then we'll try editing a page again.

We'll make a simple edit.

And click the Submit button and we'll see that our changes are saved and

we're redirected to view the updated page.

If we go into the pages directory in our workspace and

open the text file, we'll see the changes reflected there as well.

Our users can update existing Wiki pages now.

There's one more thing users can't do.

They can't delete pages they don't want anymore.

In the final stage, we ll fix that.

We'll also show you how to serve up a CSS stylesheet to make the site

look much better.

See you in the last stage.