So we've gone to all the trouble of making these forums like the one right now on book now, and we
have another one for searching availability for a particular room on individual rampages like this,
where I can pop up this little dialogue.
And we also have that make reservation page, which looks like this but isn't hooked up to anything
yet.
I think it's called Make Reservation.
Make Reservation.
That looks like it right there.
And it is.
So we need some method of actually handling this posted form data.
How are we going to do that?
Well, obviously we need to do a couple of things.
The first thing is let's do this one first.
We need to actually make this point to something in particular.
So if I go back to my code and I bring up that template search availability right here, it has an action
and the action is currently set to nothing.
So we need to put something in there.
Now, typically, when I'm posting from one page, but I'm on a page and I want to post somewhere,
I will use the same you URL.
So let's look at that you url.
Go back to our page here.
It's search availability.
OK, so let's copy that, including the slash and go back to our code and paste that in there.
And I don't want to get this page.
I get request, if you recall from way back when actually shows the parameters you're putting in the
page right up anywhere else.
So you have questionmark and then parameter name equals parameter value and then an ampersand if you
have a second one, I actually want to post it.
I'm going to change the method to post.
All right.
So now when I go back and look at my code here, reload this page that should show that it's actually
posting and it's going to post to search availability method post.
Perfect.
OK, so I've created that, but I now need to have a root to handle the post.
So let's go back to our code and look at our roots page.
This is our roots code and we have a get for search availability, but we don't have a post.
So I can actually duplicate that and change this to method post.
And that will now catch any requests that post to this URL and take it to a handler.
Well, clearly this is not the right handler.
That's the one that displays the page right here.
So I'm going to copy this pasted underneath it and change its name to post availability.
And that's a convention I tend to use.
So I know which handlers are gets and which handlers are posting that as a post in front of it.
It's actually a post now.
I don't want to render that page right now.
I just want to make sure that I can actually post to that form, which I can't.
But you'll see that in a minute.
And I'm going to do that just by writing, using my response writer, which is this parameter set up
here.
And I'm going to call it a method on a call.
Right.
And it takes, as you can see, when you're all over it, a bite slice of bytes.
And I really just want to put a string posted to search availability, but that's not a slice of bytes.
Now, I can cast that change its type from string to bite merely by surrounding it with this.
And that directive says, take whatever you see inside the parentheses, hear this string and convert
it to a slice of bytes.
All right.
So now I actually have a handler and I'm back to my roots page.
I'm linking to the correct handler as soon as I put the word post in front of this, that's all linking
where it's supposed to be.
So how can I actually test this well and run the application?
So it's running right now.
So I'll stop it.
I'll run it again.
Everything compiled.
That's good.
And it seems like it's correct.
And whenever I post a search availability, it's going to call this handler post availability.
And all that does is write to the browser window posted to search availability.
Let's see if this works.
And I'm telling you right now, it's not going to.
But I'll reload the page to make sure I have the latest version.
I'll put in some dates, so I'll put in the 30th to the first and I'll search.
And this should work.
But what I get is a bad request.
Well, that seems strange.
Let's go back and look at our application.
Nothing showed up here.
Do you remember way back when when I talked about cross site request forgery and when I also talked
about adding default data to our our template data?
Well, let's look at what happens here under my middleware or let's look at our roots first.
OK, here under roots at the very top, I am saying let's see roots there.
I am saying use no surf.
And that is the middleware that says ignore any request.
That is a post that doesn't have a proper cross site request, forgery token.
We've never done anything with that.
But we can easily enough.
First of all, I could just say disable this middleware like that and it should actually work.
All right.
If I stop this and run it again and come back to my page here and show the search availability page
and put in two dates, 24th to the 25th and search, it now works because I turned off that middleware.
Well, that's a bad idea.
You don't want to turn off cross site request, request forgery protection.
So let's go back and turn it on and see how we can fix this.
So I'll stop the application.
I will uncommented that now it's turned back on or will be when I run the application.
But I need some method of actually getting the data from where it is to where it needs to be.
So let's look at our render package here.
And if you recall, we have this add default data.
So when you render a template, the very first thing it does is it gets the template cache and we're
actually creating an array of request right now because we have our default debug turned on our applications,
not in production, but down here.
I call add default data.
So this calls this function at the top of the screen or the top of the page.
And I want to add some data to it and I've passed it template data and I want to set a particular value
on that template data.
And if you recall, we have one called CSS RF token, and I want to make that equal to something in
particular.
And I can grab that SRF token right from the No.
SIRF package.
So no surf.
And what I want to pull is actually the token, but it requires a request.
I don't have a request at this point, so I need to come back down here where I say are up here, where
I say add default data, I need to include error, which is going to be at his request.
And that will, of course, cause an error down here, but I already have the request right now, I
don't I need to get render templates, so I need to actually change that, render template function
and make sure that that takes a request to super http request.
And then, of course, in my handlers everywhere I'm making a call to render template.
I now need to change it to add the request to it.
We can do that in a moment.
First of all, let's finish this up.
This needs to have the request and there it is.
So that all works.
And there's only one error left here.
Let's go back up here and say no sirf CSR token requires can I use always a pointer to a request is
a better put that pointer in there and back down here.
So that'll be an hour and we're going to request has to be a pointer here.
Now all the air should go away.
So the last thing I have to do is to go back to my handlers and everywhere I'm calling that request
or calling that render, I need to pass in the request so we can actually look at the format here.
And it says it requires a response writer, a pointer to a request, the template and the template data.
So right before the template data, I just put in my request, which I already have.
Every time I rendering something, I have that request.
So I get that in the wrong order.
Looks like I did.
Cannot use R as type string wrong spot.
So that's not where it belongs.
Where does it go.
W dinner.
OK, so w are there.
So just me every time I call this put that request in there.
Request.
Request, request.
Request.
Request and down here to request.
All right, so that should compile now, so let's make sure we can run it and it runs, no problem.
Does that fix the problem now that I'm passing that template data, the default CSR token?
Let's find out.
Let's go back here and just go to that page, put in two dates, whatever there.
It doesn't matter at this point.
Let's see if that works.
Nope.
Still a bad request.
Well, there's a bad request there for a very simple reason.
No, SIRF requires that you have a hidden field or at least a field that doesn't have to be hidden will
make it not hidden.
First of all, so we can see how it works and then we'll hide it afterwards on the actual form that's
doing the post and it needs to have a certain name.
So here, back on my search availability form, I'm going to add input type equals and I'll make it
text right now so we can see it name.
And this is the important part.
It has to be called C srf underscore token and value is going to be equal to.
And here's where I can inside those parentheses call my default data, which I called F token.
So if we go back here and just look at our config, I think it's the config.
No it's render.
Add default data, this is of type tity, which is under models template data.
So let's look at template data.
We have a field here called CSR of Tolkan.
So let's go back to our page and actually make sure this is closed.
Save it.
And because I'm rebuilding the template request on every request, I should be able to see this now.
So I come here and look.
There is my CSR of Tolkan and if I view the source of this page, you can see it's right here.
It's a long string of random characters.
Now, if I reload this while viewing source, it changes on every request.
You see, that's different now.
So right now it starts with Kepi.
I reload the page, scroll down, and now it starts with XDA seven.
And that's what makes the SRF tokens so useful.
They are changed every single time you load the page.
So if I do nothing else now except fill in the data here 11 12 and search it posts.
So there's our CSR protection.
All right.
So let's go back to our code and let's make this input type equals hidden.
So it looks a little better and reload that page.
So we'll go back to search availability and now it's hidden, but it's still there.
We can view the source.
Scroll down.
And there it is, Berbick.
So we've got a new type for our form, a hidden type, and now we can actually submit to this.
All right.
So we can submit to it.
But what are we doing right now?
If we go back to our roots and we look at this particular path, this route, search availability matches
a post request and it calls post availability.
So in here, I don't want to just post that.
Let's see if we actually get the form data.
So, first of all, how are we going to do that?
Well, you remember on this form, let me hide this.
We actually gave the name, gave each of the inputs a name.
So this input, the hidden one, has a name of CSF token.
This input, which is our start date, has a name of start.
And this input, which is our end date, has a name event.
So it looks like I want to get start and end.
How am I going to get that out of the request?
Well, it's actually pretty straightforward goal makes this ever so easy.
So I'm going to say I'm going to create two variables start and that's going to be equal to our dot
form dot get and the name of the form input, which is start and I'll duplicate that and create one
called end are not formed.
Get dot end in this case.
So this names start matches this name over here, start on the input and this name end here matches
the name of this input end here.
And by default when you pull something out of a form post it is a string.
And that's important because you're occasionally actually a lot going to need to cast the type that
you get, which is a string into the format that you want, which might be an integer.
It might be a date, it might be a float, it could be any and lots of different things.
So I've got these two values.
Let's actually write more useful data here instead of just writing posted search availability.
Let's say the start date is start date.
Oops.
And we'll start taking this.
We'll use a format as part of S and end date is Percent.
S, and then we'll put at the end of that the values we're going to substitute in those placeholders
start and end.
And then at the beginning I need to put format s.
Print F.
As protests, all right, so what do we have here?
We have an air, we have one, too.
Looks like I don't have enough clothes in quotes from Prince's.
Probably.
Yeah, that's it.
OK, so let's recompile this and rerun it.
Stop the application, start it back up and let's go try this again, so we'll reload the page to make
sure everything is current, will choose our dates.
I'll choose the 24th, leaving on the 25th and search start date is the 24th and date is the 25th.
Great.
So now we know how to capture information from a afar, but we have more forms to search and we're going
to look at this one next.
Let's go back.
We're going to look at how we do this one, how we do the check availability, which is exactly the
same thing.
And I could pass it to the same handler and just do a post request.
But I want to make this one a little more complicated.
I don't want to leave the page when I do the search here.
I don't want to reload this entire page just because I'm checking availability.
Instead, I want to, behind the scenes, send a request to a different handler, which will take a
post request.
And I want to return the response using Ajax, which is an acronym which actually stands for asynchronous
JavaScript and XML.
But like most developers these days, I'm not going to use XML.
I'm going to use the JavaScript object notation called JSON.
So we'll do that in the next lecture.
We'll figure out how to write the JavaScript to create an HTP request.
Behind the scenes, using Ajax will create a handler to handle that request and we'll just send back
some data showing that it worked.
We're not not actually going to write the logic to search for dates yet, but we'll do that before too
long.
So we'll do this in the next election.
We'll learn how to write some JavaScript for JSON and Ajax and how to read and write the response.