Django Views: Functions, Classes, and Generics by Andrew Pinkham

Speaker 1: So, um, as just mentioned, my name is Andrew. Uh I'm a freelance software consultant. Uh and also a technical instructor. I teach Django in corporate and startup settings. Uh I have a class coming up at the end of September, which I'll come back to because perhaps most interestingly, as also mentioned I'm the author of Django Unleashed. The book is currently available for pre-order, pre-order on Amazon. And um Pearson's hedging their bets. They're saying that it's going to ship uh in December. We sort of expect it to actually ship at the very end of November, but you didn't hear that from me. Uh so the goal for today is to make it so that by the end of this talk, if you currently can't answer some of these questions I want to make it so that you look at these questions and you go, oh, you know what?

Speaker 1: I got this. I know exactly how to answer these questions. And so the goal is to make it really easy to get through all of these. We'll actually come back to the questions themselves. The talk itself is split into three totally unequal parts. We're going to start at the very beginning with the largest section, and it's essentially trying to define the problem and understand the high-level concepts that allow for the solution. We're then going to actually examine the solutions, possible solutions, and see how to interact with them. And then finally, the smallest section is going to be a little bit about the tools that might help you ease the solution process. Um the fundamentals, right, the the problem, solution, we're going to look at Python callables, we're going to examine

Speaker 1: HTTP, and this is going to allow us to Step back and look at Django views from a very high-level perspective. Then we'll actually look at views. We'll start with a little bit of a history and then we'll look at each type of view available uh in Django at the moment. And finally we will uh in enhance. Uh we'll look at a couple options that might be useful uh depending on what your choices are. I typically like to provide slides and code, and eventually I will sit down and write an article with all of this and based on feedback. And so you can find all of that material. at this link. Currently the slides are up online, so if you want to follow along you can do that. And all of the code that will be appearing, including an iPython notebook.

Speaker 1: uh which you can fool around with is uh currently posted on GitHub. So we're going to dive straight into it. Let's talk about Python callables. Um you're used to seeing Python callables all the time, right? Uh the function is sort of the the most basic It takes an input, it gives you output. This is this might seem like, okay, Andrew, why are you talking about this? This is really, really basic, but I want to make sure we're all on the same page for maybe some of the more advanced stuff. Python comes with uh anonymous functions, uh which allows you to sort of define them on the fly. They're interesting, but not really the point here. Um It should come as no surprise that methods are also callables, right? A method takes input and it provides output. Um maybe

Speaker 1: a little more surprisingly, however, is the fact that you can see that When I instantiate the class, I'm calling the class. And that is in fact I am calling it. It makes it a callable. And so some people in the room will go, oh yes, well of course. There's the dunder init method And we use that to make it so that a class is called. That's where we control initialization. Yes, it's a l it turns out that if you look at the the Python C code, it's a little bit more complicated than that. But that is in fact, yes, what makes a class callable. And you'll say, great, so we have we have functions and we have methods. And actually it turns out we can also make it so that um uh on top of functions, methods, and classes, you can make objects callable with the dunder callable method So what that means is that you have

Speaker 1: virtually everything in Python that can be a callable given certain requirements, right? And you can see here, I simply ask Python, hey, can I call this Right? So now that we all are really, really clear on what a callable is, uh, we can move into the rest of the talk. And we're going to start with HTTP. Um You've surely seen books about this, articles about this, presentations about this, and and we could we could sort of start and we go, yes, well it's it stands for this. It defines how a client and a server communicate, right? The client will issue a request method, the server does whatever it needs to, and the server is going to return a response. And at that point we could begin to talk about the the different methods available.

Speaker 1: And we could go through and we outline all the ones that are important. We can then get into a real battle about post and put and the meaning of idempoten methods. And I can stand up here and I can really go through this and you know, ye shall not and whatever goes, but that really misses The point for us, and the point is this your website must adhere to HTTP. When you were building a website The problem you are trying to solve is adherence to HTTP, right? So if I go and build a server And I have the following request methods, and then I define the following response codes. Not only will my web server not work, but I have created a monster and you really need to pull me aside and have a word with me.

Speaker 1: Um so I I'm I'm going to really uh uh emphasize the fact that When you are building a website, your goal first and foremost is to adhere to HTTP. Now I'm also going to assert a little more baselessly that the goal of all software is to solve a problem or to automate behavior. And uh I admit, look, sometimes it's really not clear which of the two things that's doing. Um, but I'm still going to tell you, yes, I am absolutely correct on this. You will take my word for it. That means that in the context of HTTP and Django, HTTP is the central problem that the web framework that any web framework must solve. It is it is everything else is a nicety, it's there to help you, but

Speaker 1: as a website is defined as just something that adheres to the HTTP spec. then that is the first problem it must fix. And it also means that you're the behavior it's automating. It's trying to make it so that you have to do the least amount of work possible to adhere to this. Whoops. Which allows us to move directly into Django. I don't know how many people here have not done the Django tutorial. Who here is really just getting started? Okay. So I I want to I'm I'm glad to see that. I just want to talk real quick about what a view is. When you do the tutorial, you're gonna see that there's some text that says a view is a type of web page

Speaker 1: Um Russell Keith McGee two years ago at DjangoCon said views are for displaying content. I'm gonna go so far as to say that it's dynamic generation of content, right? The Washington Post is a collection of web pages. Uh some of these web pages are similar, right? There are a whole bunch of articles on the website and they all meet the following structure, right? The the articles are all the same thing. And so you typically, if you were building this in Django, would have a view for the articles, right? It becomes a type of web page. So you have your user show up and what's going to happen is they're going to is that oh yes, they're going to issue an H E P request. The website's gonna compute and it's going to get a response back.

Speaker 1: W this is how every website works, and we're interested in the internals In Django, you're going to start by building Django models. You might go ahead and build forms. Oh yes, you b generate the database based on the the uh the Models. Uh you're then gonna go ahead and make uh template files, and which allows you to build the views. If your website's really complicated, you might have middleware and context processors. At which point you'll then load Django, it will get you the following tools, and you can now work with this. Your user is going to, just as before, issue an HTTP request, it goes through the middleware, gets into the dispatch It will find a URL pattern and then find a view. The view might interact with a model. It might interact with forms.

Speaker 1: And it might go and interact with the templates. It's then always going to return back to the user the opposite way through the middleware and then send it back data. Um You'll notice that in all of these cases I said might, because the truth of the matter is that this is the only thing that's really important. Right? Everything else is simply a way to try and uh I'm glad that got laughs. Um this is this is simply uh this is the core of Django. This is the only thing that you would really need to be a web framework. Everything else is really useful, phenomenally helpful. But this is this is the heart of it. Before we go any further, I want to note that that was a simplification, that animation is nice, but it doesn't deal with all sorts of things.

Speaker 1: And so Um please don't email me about the fact that it's wrong, I know it's wrong. Um what wrong, right? Um So we're going to focus on this, and in particular, we're going to focus on views. Now, because views are so heavily tied to URL patterns, I'm going to have to deal with URL patterns a little bit. And the entire goal is going to be to deal with views in the context of HTTP. So this is an HTTP or the format of an HTTP method. This is what your server actually expects to receive. when it comes in. And we have these two systems and they are going to be looking at that request and trying to handle it. The first thing is it's going to the URL pattern is primarily interested in handling the path to the resource. It looks at the URL path and it goes, yep, I am trying to figure out which view to call, and maybe it will take that some

Speaker 1: information from the URL path and hand it to the view. Maybe not. But that means that the view is really interested in the HTTP method. There's nothing else in Django that's going to handle that for us. This allows us to come back to the original question, which is What is a view? And we can look at it from a much more technical standpoint now. We accept an HTTP request object, at which point we are going to in the view generate data based on the HTTP request method. uh any data that is coming along with the request and any data that the URL dispatcher is giving or is taking from the URL pattern and then handing to our view. At which point the view will always, always, always

Speaker 1: Return an HTTP response object. That should be ringing a few bells. Oh look, it's we have to accept and we have to return. The secret to views is that any Python callable can be a view. Which sort of raises the question, why do we talk about functions and classes and generics? Why do we limit it to this? Let's take a trip down memory lane. Back in 2005 when Django was nothing but a tarball. Uh the the uh official recommendation for building views was to use Django functions.

Speaker 1: We now know that that's not really because functions are sort of any sort of inherent part of Django, but simply they're the simplest form of Python callable. And so that were they were what made the most sense to use. Very quickly thereafter People said, you know what would be great? We're constantly reprogramming all of these web pages again and again and again. Could we just put them in Django so that we can just use them straight out of the box? People said, yeah, sure, that sounds like a great idea. Um there's a problem with this, right? When you when you try and have extensible and or or you have this behavior and you say This is almost exactly what I want, right? This is almost exact exactly the behavior I want. It's just a little bit different. Functions are rigid, right?

Speaker 1: You can't sort of just dig in there and change a little thing. You have to use the function entirely or not at all. Um and that sort of became a problem with the generic views and they said, can we can we do this better? Oh, we can try and extend the number of parameters, we can do x, y, and z, and eventually they realized, oh, we're re-implementing object-oriented programming. Well that's ridiculous. Why don't we simply use a class to instantiate objects that are views? This was um A pretty successful idea, right? This is this is uh Alex Gainer saying, wow, this would be so useful. I'm sorry if that's not large enough. Um It's so useful to have, right? We'd be able to go ahead and just extend it.

Speaker 1: Um and so in in 2008, Joseph Kokerhans, I'm sorry if I'm mispronouncing that. um went ahead and opened a ticket and so the discussion became well we're going to fix generic views by allowing them to be extensible but first We actually need a class that is a view, right? We need to be able to instantiate just a simple object view And so they said, well what do we want for that? Oh well we we need to make sure that when people are using it, it's really obvious how to use it. We need to make sure that it's extendable, because that was sort of the original idea, and we need to make sure that it's thread safe Turns out that last one's really hard. And so it took until 2011 to really get it right. To really sit down and say, okay, we're gonna work through the entire thing and get it right.

Speaker 1: And at which point they released the class-based view along with the generic views. And this is sort of where we ran into a naming problem. Because we'd started with generic views, and that was it was obvious what those were, right? Like, oh, it's just behavior that's pre-programmed for us. And now we've introduced this class-based view, right? It's just a view that instantiates an object view. Or it's a class that instantiates an object view, excuse me And they said, well, we'll just add class-based in front of generic. Everyone will understand, right? There will be no confusion there. Unfortunately, there was a lot of confusion. And there's sort of there remains a lot of confusion. One of the ways um I've started discussing it is to talk about class-based views as object views. Yes, there's a class, but the the actual views are the objects that you're instantiating, and that helps a lot of people go, oh

Speaker 1: yes Of course. Um and the other thing is that the the main point of the generic views is not that they're class-based or objects. That's that's certainly incredibly useful for extending behavior and taking control, but that's really not the point. The point of the matter is that they're generic views. And where that leaves us, the state of the the the pony, uh as of Django 1. 3 Oh, for all of the the the beginners in the room, uh the State of the Pony is is a joke, uh longstanding Django joke where we talk about um People saying no, you can't have that pony in terms of new Django features, and so you will regularly hear people say the state of the pony to refer to the state of Django. I did not think about that inside joke. Uh sorry about that. Um so we we currently have three options, right?

Speaker 1: The function views simply because it's a callable, right? We can use any callable and so naturally you you can use a function view. And and then the object views or the class-based views are there and useful because They put, you know, three years of time into really making sure it was safe and usable. And so people don't create their own because It's a lot of work to do that, and why wouldn't I just use these? And then the generic views are simply pre-programmed views for you to use, and so you know, not really in the same category. And that means that we can now move into looking at each one. Um so the function views uh we now know, even though they're considered the original It's simply that they follow what it means to be a view and they're callables, right? Um so we're gonna begin by setting up a uh a little project.

Speaker 1: This is a model, it's really uninspiring, but you get the point, it's got a name and a slug Because I can't get away from building views without a URL pattern, I'm going to go ahead and build a URL pattern. It's going to call my view and it takes in a single parameter called the slug. Um this allows us to program this, and this is sort of your stereotypical view. For all of the beginners uh in the room. This is this is sort of how we think of views. I take in some data, I fetch something from the database, and then I return something via the template. This is not a great example, unfortunately, because it means that I'm using all of these other subsystems When I meant to just focus on one

Speaker 1: thing. And the only thing that really matters is you can see the first parameter I'm taking in. is the request and the render is using that to return an HTTP response. And so you can see the the idea here is that we're doing that. Can anyone tell me what's missing from our stereotypical view? Does anyone see something that's that's that's sort of should maybe be in there? Feel free to actually shout this out. I'm actually asking you a question. The method, yes. We haven't bothered to handle the HTTP method at all It's it's not even in our code. There are many ways we can do this. It's fairly easy, right? I can just add an if condition and say, look, if it's the get method, um, you know, do the following.

Speaker 1: And if it's not the get method, please return an HTTP response not allowed and tell them that the only thing we accept is the get method. This is horrible. You're not gonna program this. Come on. Like not that's not great. Thankfully, Django introduces the HTTP uh the uh decorator, I'm not gonna get that up, um, to help that. And so here we simply say, look, this view Um it only accepts get and head and everything else it will return an HTTP four oh five method on or uh Return an HTTP response for a five error code. There we are. Um turns out there's a shortcut a shortcut for get and head uh called require safe, and so we can simply move that over. And

Speaker 1: At which point we can actually see all the changes to our code by using a tool called Telnet. You can actually write the HTTP the uh HTTP request directly in your command line uh if you're running a server. This is actually kind of fun, right? So I'm actually typing in get a path and it is returning this data to me and I can see oh yeah that it it expects that and it gives that stuff back to me. If I give it a a method that is it's not expecting, like options It's going to say, nope, I have no idea what this is. I'm not programmed to handle this. And uh what I can tell you is that uh I can handle get and head. You can see that on the third line from the bottom. You'll notice that throughout this talk I'm going to avoid a post, even though it's commonly used, because the CSRF middleware is going to get in the way and simply kind of interject itself and go, hi, by the way, you're not being secure.

Speaker 1: If you were to disable it, you would get a 405 error. Please don't disable it unless you really, really, really know what you're doing. We're going to go through and we're just going to create another view just to see a slightly different case. So here is just another URL pattern. and here is a view and you'll go, oh look, this is for handling forms. And we say, oh okay, so if it's a post, I behave a specific way. And if it's not a post, you know, I expect a get and uh I I behave a a different way. Um that's like showing up at your 24-hour diner and 90% of the time you're gonna say, yes, I would like the scrambled eggs, and you're going to so people are going to to ask for scrambled eggs 90% of the time. And so you're just gonna give them scrambled eggs.

Speaker 1: But you're also for 10% of the time giving the people who are asking for hamburger or the hash browns scrambled eggs That's really frustrating and you're probably not going to do well with that crowd. And so even though you're handling post, you're not actually handling any of the other HTTP methods, right? You you can see that it's um I sort of brought a laser, and that's not working. Um you can see that the the topmost condition there, the else, simply says else. It doesn't check for any other HTTP method. And that's not so great. So even if you're partially handling the HTTP method, you really do want to think about whether you're handling all of them. And that's how you should deal with function views in Django.

Speaker 1: Um we can now turn to class-based views. And the key advantage to class-based views is the fact that they're classes. You're dealing with object-oriented classes programming. And it's a really powerful way, not the only way, but a very powerful way to adhere to dry, which is don't repeat yourself. in Python. So once again we're going to we're going to convert the last two views that we had that we built into class-based views Um I have to deal with the URL pattern, I can't go into I don't have enough time to go into detail as to why I'm changing this There's a lot of documentation and I cover this in great detail in my talk at DjangoCon 2013. The bottom line is you'll have to believe me for the moment that I have to make this change for this to work.

Speaker 1: Um we can then actually look at our code and the first thing I'm going to do is get rid of the decorator. It's gone. I don't need it The next thing I'm going to do is change the name of this function to get, and I'm going to add self in anticipation of having this as a class. I indent And I put it under a class. That is the only difference, right? It is exactly the same thing, except it is now it now has a s a class that it belongs to and is now a method. Um there is, however, a huge amount of beauty to this because it makes explicit the problem you are trying to solve. This code only works if an HTTP get method is used. And everything else is not handled, or rather

Speaker 1: will return to four oh five error. Um almost everything. As it turns out Class-based views are kind of neat. If you give them a get method, they will automatically give you head method handling, and it will also always give you option handling. which is really, really cool and much better than what you're getting with with the function views. The same thing is is sort of similar when we come back to our form view. And we say, oh, okay, well we need to do a little bit more here because what we actually wanted was get and post, and so we can go ahead and create two methods for the class-based views. And we're going to go ahead and define a bunch of attributes. The get method is completely uninteresting, right? I take input, I provide output to a page.

Speaker 1: Not root the code is not really the point, input, output, just the get method. And with post, it's sort of the same thing. You handle the form however you need to, but the bottom line is that this is behavior that is defined only for the post method. Um and of course you're getting options and head because of the way we've we've built this. This is um very different from what we had originally. And one of the the things that I found um with beginners is If you if you look at this as a beginner, it's it's kind of a lot to take in. You go, well, there's an if condition, but then there's a second if condition, and there's this implicit return that has multiple behavior. And when I ask people taking my class, how many behaviors do you think is in here? The answers I typically get are either two

Speaker 1: or four. When the truth, if you look here, is that there are three, and that becomes much easier to see in this context. So CBVs, despite the fact that we say, or class-based views, despite the fact that we say are more complicated and take a little bit more of more code. can actually be used in certain contexts in really interesting, very helpful ways. So part of this, if you're totally new, you may not know why I'm defending these quite so much. There's a certain uh when they were introduced, because of the confusion around them, a lot of people said, well, they're they're not worth using at all or ever. And so part of my position is wait. These are a tool and tools do have purposes and can be used in certain contexts

Speaker 1: as long as you understand what the tool does and when those contexts are. So I'm just trying to provide when and the context. This allows us to sort of look at the the odd um view set in in the game, which are the generic class-based use. And I'm just going to dive right in because there's so much here. And you can see that this is all of model detail now, right? I've completely removed the get method. It's nowhere. I'm just sort of in invocating this Um and this is this is feels awful because you're looking at this and you're like, well wait, this is like a game of mad libs. How do I know what to fill in or how to fill it in? And this gets even worse with With the model create. I've removed get and I've removed post, but the attributes are exactly the same as they were before. And I mean, at least you have some small comfort in saying, well, it's exactly the way it worked before, right, Andrew?

Speaker 1: No, it isn't. No, and and that's sort of the problem is is suddenly on our new form we now have the put verb which has been instantiated. And you go, okay, well hold on, let me let me sit back and go through this. What does this look like? That's the actual graph of how all of the c generic views are related. It's really kind of insane. And when I gave my talk at DjangoCon 2013, this is the image that I presented. But you feel you take so much time going, oh I have no idea what I'm doing, I don't understand. The point really wasn't that It's a terrible idea because if you start using generic views, it turns you into a real powerhouse. I mean you you can become a supercoder. You will leave websites in your wake. The problem is

Speaker 1: that you spend so much time doing stuff that doesn't make any sense to try and get there that it can be really frustrating. There are tools that are very helpful, and we'll come back to this one. But the idea for um the idea here is that if you're a beginner The idea was that by having these be classes, we would be able to go ahead and extend them. And by overcomplicating them, it's become a bit of a problem because beginners go, well, how do I extend them? How do I learn how to go about them? And unfortunately, my advice is that if you're a beginner Don't right try and use them. If you see that there is a generic class-based view that does exactly what you want, use it.

Speaker 1: See how you just get it to do exactly what it was built for. If you then once you've become comfortable with that, then begin to go, oh, okay, well maybe I can begin to look at the methods There's this thing that happens. You can see it on the mailing list. I see it a lot in my classes where people go, oh, I would like to use the following generic view To do X, Y, and Z? And the answer is always, well, yes, you can do that, but there are better options for how you can go about building that. I really thought that was going to get more laughs. Really? It's nice to see a little contingency over there. Okay. And so that's that's the thing, is that with with generic views, yes, you can absolutely customize them to do whatever it is that you want.

Speaker 1: But maybe it's not always the best idea to do that. And unfortunately, the only way to figure that out is to get familiar with them. And that's sort of unfortunate. So Now that we understand really how all of these work, uh, how do we sort of tackle the problem of using and building views? Um for the function views and all of that jazz, uh I think it's fairly straightforward. I do want to take a quick look at classy class class-based views. Because last time I presented this and the last few times I've given this or similar talks, the Most people go, wait, could you show the tool? How does this actually work? So you're going to show up on this website and it's going to show you all of the generic views at the top level.

Speaker 1: And you can click on any of them. And so I'm going to click on detail view, and it's going to show me uh all of the classes that are related that this view inherits. As well as it provides a link directly to the documentation. And below this, there are the attributes. These are all of the attributes that I can override, including their current defaults. So that I can see exactly what is going on. This is really where you want to start, right? If you if you decide, oh, I'm going to use a generic view, I'm I'm going to go ahead and I'm going to try and figure out which attributes I need to define. Once you're comfortable with defining the attributes and going, okay, yep, I can get that behavior by changing just attributes. You can begin to look at the methods, right?

Speaker 1: This is where you go, yep, totally comfortable with the attributes. but I need to just tweak this one thing. This allows you to see all of the methods that are being used. You'll typically want to start with the methods that The class base view uses, right? Get, post , put. So right here I can just click on get and it will show me the implementation, as well as tell me where it's actually defined, because it's not actually defined in detail view. If you look all the way to the right, you can see it's defined in base detail view. Um Uh and so that's that's class-based, they're classy class-based views and sort of the go-to tool for trying to get through generic views. Um I'm also, when I was building

Speaker 1: when I was writing my book, when I was compiling my book, I found that I spent a lot of time writing decorators in Django to get it to do what I wanted And I'm slowly going to be taking them and putting them out onto the internet. And so I've started a project called Django Decorator Plus Uh I'm a little burnt out from book writing, to be perfectly honest with you, and so I haven't gotten as much work done on this. But Uh I do have my replacement for the require decorator for function views because I think it's silly that the class-based views gets you options and head out of the box but that the the decorator doesn't. So I fixed that and I've gone ahead and recreated the decorator. These are two shortcuts for the decorator, um, and they're equivalent to just get

Speaker 1: and get post. But again, you know, I say get, but that's actually get head options, and get post is get post head options So I'm hoping that that will um provide the basis for for adhering to HTTP methods um or adhering to the HTTP spec um in uh function views. Sorry, I keep getting distracted by the timer. Um which brings us to our conclusion. Um I wanna we can come back to these these question or the the the yes, the questions that I I was hoping you would find easy at this point. Make hopefully these these are sort of um tacklable, if that's a word. So

Speaker 1: Django handles HTTP for me. Why do I need to worry about it? Well, as we now know, it doesn't handle it for you, right? It will translate the HTTP into a nice Python object and allows you to manipulate all of that data and to easily use that in in Python, but it's not handling it for you, right? You are still taking care in the URL patterns of the URL path to the resource. Uh and and in views, you really do want to be considering at all points what HTTP method is being used and how you react to it, because otherwise you're you're building an API that is only using part of the information. And some user on the other end is going to be really unhappy with you. Um when is Django deprecating function views? Um

Speaker 1: it's not. Right? The idea between behind a view is you know accept specific input, provide specific output, and any callable can can be that. And so function views are not anything inherent to Django um and they're not going anywhere. Um aren't all class-based views generic? No Um hopefully the the walk through history helps um split the difference, right? The idea is we have generic views and that is very much its own concept, and then we have object views and that is very much its own concept. And we th there is some discussion about whether each one solves the problem it was designed to solve And those are valid conversations to have, but it's difficult to have that conversation if

Speaker 1: people continue to confuse the two. Finally, how do I choose what kind of view to use? This is easily the hardest question on here. Um and I have a set of questions that I ask myself whenever I'm building a view. And the first is, is there a generic view that does exactly what I want or almost what I want? And can I simply plug into it? If yes, use a generic view. You know, it's there for just that. If there isn't, you're sort of left with the choice between a class-based view and a function-based view But we now know that they're eff essentially equivalent. The only reason that you might want to use a class-based view is if you have behavior that is shared across multiple views, at which point using object-oriented programming

Speaker 1: is incredibly helpful, but if you don't, it's entirely up to your preference. You could use function views or class-based views. It doesn't really matter. Which brings me to sort of the key takeaways. The view is Django's solution to handling HTTP Um all views are callable, call or Python callables, doesn't matter. Please use the require HTTP methods if you are using uh function methods, or at least consider how you're handling HTTP methods. And finally, please think of the two concepts of generic views and class-based views as very different, very separate. Thank you very much all for coming.

Speaker 1: I hope this was helpful. Again, all of the related material is at that first link. My book is currently available for pre-order and it's currently discounted Amazon is in charge of that, and they won't give me an answer as to whether the discount remains after or if that's simply a pre-order thing, but It's currently discounted. And finally, at the end of September, as I mentioned at the beginning, or the the beginning of October rather, I'm going to be teaching a class in Django locally as a thank you for all coming to this. That is a promo code that you can use for 20% off. Um questions? I'm also if we're out of time, I'm happy to take questions in the hallway. I have I have 40 seconds. I'm sorry for I cut this so close and that we started late.

Speaker 1: Are there any questions? And again, feel free to just grab me throughout the conference if you do at any point. I think there's a there's a mic. Uh

Speaker 2: based on the flexibility of a class-based view, doesn't it and the fact that it gives you all those methods to define kind of for free, doesn't it make sense to always use a class-based view over a function view? Because you'll need to deal with the other methods? Um

Speaker 1: it's it's sort of your pre it honestly is is really your preference because At that point, you know, it it will get you head and options, but let's say that you're using the decorators from decorator plus, you get that same behavior in a function view for just calling return. And there's so there's really very little difference uh if it's really a very, very simple view.

Speaker 2: Is there possibly like a performance optimization overhead for or perfor uh you know a performance hit for using a cla class method over

Speaker 1: There might be a small performance hit, but that's I mean that's not really where your performance problems are going to be. Typically your performance problems are going to be in I. O. Yeah. Okay. So

Speaker 3: cool.

Speaker 2: Thanks.

Speaker 1: No.

Speaker 3: Hi. So I'm wondering about um, you know, let's let's say for example you have uh uh a model or an object of a model. Uh such as like a a task and you know you can perform different modifications on it, right? So I guess you would use like an update view or something something like that as a class-based view. If you wanted to modify it in different ways at different stages of time, uh Do you have a recommendation on on how you would do that? So like uh you know let's say uh at one point the task is unassigned and then uh you post that it's been assigned to a particular person. I'm thinking of you know a sort of simple ticketing system, right? Sure. And then uh

Speaker 3: the person updates it and so they post, you know, the status of it and then eventually it gets closed Could you handle all of that in a single class or would you split it into different URLs? Do you have any thoughts on that

Speaker 1: That depends entirely on how you want to handle it. You certainly could have a single edit view where you can change all of this, um, all all of the the um fields on the model. Um Uh you certainly could have multiple, right? You you might just have one where you click on it and it immediately updates and changes a status uh flag. So it's sort of up up to you. I may be misunderstanding the question though. I'm not super clear on all the details. I'm happy to talk about it afterwards. Thank you all very, very much for coming. I hope that was helpful. Feel free to grab me uh during the conference if you have any questions. Thank you again.