Adding a CMS to Your Flask Web App Transcripts
Chapter: A tour of our demo application
Lecture: Exploring the starter source code

Login or purchase this course to watch this video and the rest of the course contents.
0:00 Now you've seen our Web app running. Let's pull back the curtain and have a look at the source code how we built
0:07 it, some of the patterns that we're using so that you can get in here and work with it yourself. We're gonna go pass after pass after pass,
0:14 making this better and adding features and so understanding the overall structure is important.
0:19 So we've got our project. We're using a limbic for sequel. Alchemy. Migrations. If we change the database, we won't be messing that without much.
0:26 But that's here for when we do need them. Then this is the main section of our site. This is where most code is.
0:33 We have some server set up for deployment and then also some unit tests. We can run. You dig in here, there's a couple of files. There's some stuff,
0:40 especially this load. Data one will take the source data and import into the database
0:45 For starters, you won't need that because we're using sequel light. And I'm gonna include that right here. That file for you and you won't need it.
0:52 But if you want to import this into a more proper database, you can run this and change the connection string and it will go there.
0:58 Speaking of sequel alchemy. Were using that over here. And so we have things like the packages and the languages.
1:06 Let's just look at the packages for a moment Over here. We've got our package. It drives from this common sequel Alchemy Class.
1:12 We just have all the columns here. I, for example, have an I D, which is a primary key, but it's a string that happens to be the package
1:19 name, and we even have a relationships between the packages and the releases.
1:24 We're not going to do a whole lot messing with the existing sink welcoming, but we will need to add some stuff. Years. We'll come back to that.
1:30 Let's go look at our views. Next, I suppose. Let's go look at this package to remember. We were looking at that, a WSC ally,
1:37 and it had details about when it was released. It had its description, its home page and so on. That is, this section right here.
1:45 So were using a lot of organization. As you'll see throughout this whole project, we've our views. They hold view,
1:53 implementations, categorized, buys a package home accountant. So on. And then we have details and we have popular and we'll have a
2:01 bunch. More pieces were adding. Then over in our template section, you can see we have for our package views.
2:07 We have a package folder and then we have a details. And if we actually had a thing we rendered here rather than just a string,
2:14 we would have a popular about HTML as well to in here. We're going to the database, and we're checking for the package and seeing if there
2:23 is a package. But we're going to give the details back, and there's not We're just going to say 44 page not found in our flats cap
2:29 We're using this custom response decorator that takes let's a specify a template file and map a dictionary to it instead of using flask.
2:38 Render template. Think it's a little bit cleaner. So we're using that were also using blueprints to help categorise your organize our code into
2:46 these different sections here, so that we don't have to try to juggle specifying the
2:51 routes. So we'll come back and play with that when we create these new view sections for like CMS and admin.
2:57 And why not? Finally, I guess one of the things that's interesting here that is somewhat unique but is a pattern I really,
3:03 really like. So I think it massively makes testing easier. And it makes it more possible to clean up your code around these view methods.
3:11 Here is something I'm calling the view model pattern. So notice here. We're creating this package details view,
3:17 model, and we're passing the data that comes in here to it. And in our view model section, just like our templates and other things,
3:22 we have the same type of organization. So here's age details for a model. I think it should be called package details.
3:29 And rename that for you. I don't know how it got called that package details
3:33 So we've got this view model here and wouldn't we created its job Its purpose of all these view models. Maybe a more interesting one to look out for.
3:43 This is this log in one. The job of this is actually you manage the data exchange between the view method in the HTML file. So, for example,
3:51 when you log in, gonna have an email field in a password field, you might also need to show them an error.
3:57 So what we're gonna have this thing do is it's gonna go and figure out what the values were submitted and then what validation needs to be done like,
4:05 Hey, you must have an email if you're trying to log in or you must set a password if you're trying to log in.
4:10 So it basically takes all the data access and data exchange with the HTML side of things away. If you want to test it,
4:17 it makes it a lot easier because you contest this outside of the Web. App basically got to do a little bit of something to mock that out.
4:23 But other than that, it's pretty simple and straightforward to dio now the final thing
4:27 in terms of organization and patterns that we use that's pretty cool. Is this thing called services? Not like AP eyes not like Web services,
4:34 but just this concept of taking all the data access and data, juggling stuff and organizing again by category.
4:42 So, for example, here we're talking about getting packages, and so we're using this thing called the Package Service.
4:48 Now the package service. If we go to it now here it's Job is to have all the data access and other behaviors around packages.
4:56 So get the latest release just in general. Tell me how many packages air in the database. Hominy releases. Given a package,
5:03 I d give me the package details and you can see this is just standard sequel alchemy. Here they were going through,
5:09 creating a D V session and then doing a query and then closing it out. And we also just ask for all the packages.
5:16 Super straightforward. But that's over in this section, we have one also for users. How many users are there? Find me the users by email.
5:23 So on, we're gonna have a couple more of these that we add one around
5:26 probably administration, like creating new pages and whatnot and then one around just working with the M s request directly.
5:35 All right, well, I think that pretty much covers it. One more thing, I guess if you look at all of these pages here like
5:41 let's look at the long and page, you'll notice that they all extend from this common lay out here. There's really not very much on this page,
5:50 even though if you look at it, It's got all the navigation, everything.
5:53 And that's because down in this shared section is where everything is really happening.
5:57 And then we're just dropping in a little bit in the middle of whatever that page has to contribute, right? You're the footer down here.
6:03 We have all the navigation up there, so it makes it really easy to just add the essence of what each new page
6:08 needs. And so we're also using this relationship between those things. All right, that's it. That's the site that we're gonna be working with.
6:16 You see, it's not super complicated, but it's also not a toy app. It does quite a bit. It has a lot going on.
6:23 And so adding the CMS major to this is gonna be really cool because it lets
6:27 us take all the work in all the power of this great application and then and
6:32 this other aspect to it, where we can create pages without going through all the
6:36 details of this work. But just here's some standard HTML content that we want to
6:40 have in different sections, like the help page and the Donate page and so on

Talk Python's Mastodon Michael Kennedy's Mastodon