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 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.

Talk Python's Mastodon Michael Kennedy's Mastodon