Building Data-Driven Web Apps with Pyramid and SQLAlchemy Transcripts
Chapter: Introducing the Pyramid framework
Lecture: Building block: Views
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
So, let's dig into these building blocks. First of all, we have our views or controllers. So, what does that look like?
0:08
Well, we start by importing the necessary decorator, from Pyramids, so from pyramid.view import view_config, and then we just define a function.
0:18
The name of the function doesn't actually matter, in this case, and then we're going to map... a route... to that view.
0:27
In order to make a regular function become one of these controller functions, or actions, what we're going to have to do is
0:34
we put this @view_config decorator. Usually what you'll find is there's at least two values you set, sometimes it can be omitted,
0:42
sometimes there's more, we'll talk about that... Is we're going to set the route name. This is what URL maps to this function, it's a route name.
0:52
And then the template that we're going to use to generate the dynamic HTML, so that's the renderer, we're going to use mytemplate.pt right now.
1:01
And then this method always takes a request object. Which is one parameter request, and that's the way it works.
1:08
The request carries with it things like the data passed, and the URL, the form post, all that kind of stuff.
1:14
It's sort of the jumping off point to get the data out of all the inbound stuff, and things like cookies, and so on.
1:21
We're going to take that data, do whatever it is we got to do, maybe check for an account, maybe pull some stuff from the database, things like that.
1:28
And then when we're ready we're going to return our model to the template. We do this by returning our model as a dictionary
1:35
and the framework is going to manage getting that moved over to the template and rendered dynamically and responded back as HTML to the browser.
1:46
This is about as simple as things get, with views right? All we do is we have a function, it returns a static dictionary.
1:53
Let's look at a more realistic one. Over here, we have one and we're saying this actually only responds to POST messages.
2:03
We're going to reset password and maybe there's one that generates the form but this one is going to do
2:07
the password reset when they submit that form, okay? And first of all we're going to get the data that they put into the form, right?
2:15
What is your email that you're going to reset your password to when they click the button? All that data from the form
2:22
ends up in a dictionary called POST. Alright, we're going to grab that out... And then we're going to try to create
2:28
a password reset using our data access layer. That may or may not work, but if it doesn't work, then we're going to send them an error saying,
2:36
"No no, sorry that didn't work," and we're going to render the reset password again, but this time the error message will be shown.
2:44
And if it does work then we're going to say, "Alright well it looks like that worked," so send them a message that says,
2:50
"Check your email for the reset code." Presumably that repository thing actually sent the email. Not sure that's a great pattern
2:57
but it fits on one slide, so that's why it looks like that. Alright, the idea is we call that function,
3:02
and either it did not send the password or send the email, or if it did it saved it in the database, sent the email,
3:08
and now they just got to go check their email. Alright this is a more realistic type of view here processing a form POST.