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