Full Web Apps with FastAPI Transcripts
Chapter: View models and services
Lecture: Benefits of using view models everywhere
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Let's go look at our views one more time. We're just about there. We've got our account stuff going on here.
0:05
Account views with their various view models, and we've got the home view with it set up. And the package view going on here. These are all good,
0:13
but if we look here, there's this one we left this TODO. Remember that? Let's see one more thing to do with these view models that is
0:20
really, really valuable. So one of the things that you often want to do
0:24
is provide some feature, some functionality, to every single part of your application. Every template. It's just gonna be common across there.
0:34
So let's look at a really straightforward example that's over here in shared. I've got this login and register.
0:43
Well, guess what? What if I'm logged in? Do I still want to see login and register? No,
0:47
I want to see a link that says your account and a button that says logout. Wouldn't that be nice? So how do we do that? Well, it's really super simple.
0:58
Over here in Chameleon, you just say tal:condition, and then what? Like, is there a user_id?
1:04
Let's say that that's gonna be something we can get really cheaply because it's gonna come from the cookies, which is just a dictionary,
1:10
not from the database, which maybe would be more work. So instead of testing for a user, we're just gonna test for the user_id.
1:17
Maybe a better way would be, say is_logged_in, are logged in or has_account or something like that, right? Make it a little more abstract.
1:26
That would be nice to have. We'll say that we don't want. It's gonna, It's not the case. And if it is the case,
1:34
then we want to say, change these around a little bit. So if you are logged in, we wanted it to go to just /account,
1:41
and this is gonna say "Account" and this is gonna be/account/logout and down here it'll say Logout. That's great, right? Let's go and run it.
1:57
Mmm, not as great as I was hoping. Probably not as great as you were hoping either. What is the problem? without looking. It's
2:04
NameError: is_logged_in not found. Right there. It doesn't know what the heck that is. So what we do is, we go to our base view model and
2:20
it always pulls this and sets this. I'll say self.is_logged_in = False. And then maybe a comment, right. We'll set that from a cookie.
2:31
And it'll be really straightforward. So what's gonna happen is, the view model,
2:36
anything that is either this or derives from this is going to have that information. So every single view now should have that info there.
2:45
And what is our problem? Oh, I said case, didn't mean case. I meant condition. Somehow I got that, condition. Sorry about that.
2:53
I'm sure you noticed that and you were like: what is going on here? Condition, I said condition, but autocomplete gave me case.
3:01
There we go. Again, perfect. Now, right now, we said there's nobody logged in and notice if I go to any page on the site.
3:09
Always working, go over here to our ViewModelBase and just say True. And obviously you wouldn't just hack that and say,
3:17
of course, you're always logged in. What you would do is get that from user. But check it out. Now we have Account and Logout.
3:24
Have it over on the home page, we have it on this page and so on. But if we don't use the view models everywhere,
3:32
remember our about page? Crash! Again, all of a sudden, what is going on with our site?
3:38
Well, here's that NameError that I was telling you about. In this particular view,
3:42
that information our shared layout needed, didn't get what it was expecting. So it crashed, right? So these view models provide a really nice way to
3:50
send that information to everything as long as everywhere you use it. And if you don't need any details,
3:56
we can just say return the to_dict() or just the base, right? We didn't have to go create, like, an AboutViewModel here,
4:05
but by using it everywhere. This is working great. There's other ways to do this, the view models provide a really nice mechanism.
4:11
And if you're using them in most places, just use them everywhere and you'll be good. So back here that works, this one works,
4:17
everything works. Great, just one nice chance to show how this ViewModelBase provides
4:24
common data and common functionality for the entire template engine. Well that's it for view models. I hope you found this way of
4:33
partitioning our logic and data exchange into view models and services really nice way to keep
4:39
things like our actual view methods really clean. Create some
4:44
testable little classes that we can test in isolation and provide common functionality to the entire template engine.