 Audible at the back. Thank you. So hi everyone. It's great to be back. Python is always an amazing experience to share insights and discuss about code. So I'd like to talk about design patterns in Django. Django programmers in general do not talk much about object-oriented programming or design patterns. Not that much as maybe Reigns or Java community. I think I see it as a deficiency and I think we could talk more about it and this talk is just trying to trigger that kind of conversation. Hi, my name is Arun Revindran. I blog and I have screencasts posted at ArunRocks.com. I recently opened source to a project called Edge which is a project template for Django. What you see down there is a shameless self-promotion. I'm actually writing a book about Django design patterns and best practices. It will cover almost 40 to 50 design patterns and best practices covering Django 1.7. It will be published by Packet Pub by the end of this year. So here's an outline of what we're going to talk about or cover in the next 30 minutes. I'm going to talk about why we need to talk about design patterns. What kind of design pattern we use in Django, especially the broad design pattern that the NVC design pattern which is a common question which people have. We're going to cover about nine common design patterns in Django. There's going to be a lot of code. These slides are going to be uploaded online, especially on the top page, so don't worry about that. We're going to discuss about the code as well, so we'll have fun. So this definition of design patterns might be familiar to some of us. Design patterns is basically a reusable solution that can be applied based on the context for a software problem. Interestingly, it's not starting with software that design patterns actually started with. So around in 1977, Christopher Wolfgang, Alexander collaborated with other architects to write a book called A Pattern Language, Towns, Buildings and Construction. So he's an architect in the traditional sense, not the software sense. And he wrote a book which covers about 253 different patterns. And when I say patterns, he's actually talking about a certain problem which commonly occurs in the field of architecture and a solution in terms of what is a practical solution to that. So this book was a little bit controversial because in his opinion, users should be the best judge about what a good solution is, not an architect. So this practice of this idea has slowly creeped onto the software world as well. And most of us are familiar with the Gang of Ford book, which is where design patterns really became popular in the world of software architecture. So that is not the only book about design patterns. There have been several other books about design patterns such as Martin Fowler's book on architecture, Enterprise Architecture Patterns, Refactoring into Patterns, and several other books which are considered as pattern repositories. They contain a lot of patterns in the form of easily reusable collections. So some of us might be wondering, when we are talking about web application development, there are hundreds of things to worry about, especially when we are talking about a production application. There's database design, there's web design, there's shabbing, there's caching, thousands of concerns. And now here's a driver's telling that you should also think about design. And you really don't have time for the most elegant design, right? I mean, we are just trying to ship code at the end of the day. And users don't look under the hood, they don't care about how it's implemented. But who cares? We care, right? We as programmers really worry about what the best solution is. So some of us have this deep inner desire to create elegant and beautiful code. We actually want to see solutions which are most effective or most elegant in terms of how it's implemented, how it's reusable, and how it can be maintained. Again, if you learn one design pattern, you can apply it to various different projects. They are repeatable solutions. It gives us a common language to talk about. If somebody says, hey, I did this implementation using public subscribe pattern, he actually saved 15 minutes of explanation. He doesn't have to tell, OK, there is this sender and there are multiple receivers listening to that. And he has to send messages to all that. All that conversation is eliminated and the person at the other end immediately understands, oh, public subscribe pattern, I understand what you're talking about. Reduces trial and error. This is very important. So some of us actually obsess over what is the best solution or whether solution A is better than solution B. We go through stack overflow. We ask our friends. We ask IRC. Hey, you know what? It actually works. But I'm not really sure whether this is the right way to do it or am I doing this right kind of questions. And most importantly, it formalizes best practices. So if you know the Django design philosophy, a lot of practices which are imbibed into it have been articulated in the documentation. There actually is a right code, right? Do not repeat yourself. Always follow separation of concerns. Use solid object oriented principles. So this is not the last one is actually not mentioned, but some of the responsibility principle list cost substitution principle. All these concepts are very well known to people who practice object oriented programming, but it's actually not well articulated in the Django community, but it's actually used as we'll soon see inside Django. So now here's a common refrain that we'll hear among Python programmers. They say, you know, design patterns. Hey, Python is an object oriented language and a scripting language. We don't really need to use design patterns, right? But that's not really true. As you can see in this slide, there are a lot of design patterns that's used in the implementation of Django itself. And before we talk about this, how many of you in the audience actually know what an abstract factory pattern is? Just raise your hands. Have you used it? Okay. How many of you know a singleton pattern? Great. So sorry to disappoint you. Singleton pattern is now considered an anti-pattern. So again, abstract factory pattern is not really required in Python because it was actually designed in a different language. It was designed for C++, which actually uses static typing, strict type checking. But if you use a function instead of a class in Python, you can actually do the same thing for creation of objects and thereby create an abstract factory. So what I'm going to say is that when you just blindly follow the gang of patterns, book and try to implement all those extra classes and interfaces and everything, ditto or verbatim in Python, you'll hear a lot of ducks quacking in the background. That's actually reminding you that Python is a duck typing language. You don't have to jump all those hoops. You just don't have to worry about types at all. So what I'm trying to say here is a gang of four patterns are not very widely used in Django implementation. You can see that there is the observer pattern, which actually is used for implementing signals. So there is one sender and there are multiple receivers. There is something called template method pattern. So that's actually used in class-based generic views. You can override various parts of the implementation of a generic view using the template pattern. But I found that Martin Fowler, whose patterns are more towards the architecture side of things rather than the design side of things, his patterns are much more really used. The active record pattern, which is actually documented as the Django implementation for models, encapsulates database access as well as business logic inside the models. We also see the identity field pattern, which is quite straightforward, which is basically storing the ID. We also see the template view, which is nothing but Django templates. So as you can see, the Django implementation or reading the source code of Django helps you understand various patterns which are used. Of course, if you have that background of what context we're talking about, you'll immediately recognize this is the pattern we are using here. This is a very common question I come across. Many people ask me, does Django follow the MVC pattern or the developers of Django say that we are not using MVC, we are using something called MTV. The reason behind this is MVC is easily misunderstood. MVC actually, if you look at the history of MVC, it actually comes from Smalltalk, which used MVC for its GUI graphical user interface. That's where all these concepts of controllers and models and views come from, which is completely different in the world of web application development. We don't have a mouse and keyboard and all those kind of things, but we have something called the request response cycle, which is happening inside the web application. So the creators with Django felt that the entire Django application or the framework can be divided into models, templates and views. So what we are trying to say here is MVC is nothing but separation of concerns implemented. Now, MTV is also a case of separation of concerns implemented. We have, if you are talking about one-to-one correspondence between models, we use controllers. You will see that models are nothing but Django models, views are nothing but Django templates and control is probably the rest of the entire framework itself, which actually works as a controller, which controls what the user is trying to send in the form of a request all the way back to the response. So according to me, the answer is both yes and no. It's kind of an MVC variant and people should not obsess too much over it because we are actually talking about separation of concerns here. So now let's get to the real meat of this presentation, which is design patterns. We are going to talk about three model design patterns here. Some of these are very familiar to you folks, so I'd be interested in hearing various other implementations, but I've gone through several implementations to find out which is the most optimal or which is the most appealing in terms of elegant code. The first one we talk about is user profiles. So almost all of us here have tried to create some user model at the other. Unfortunately, all of us think that since Django's custom user model was released when I believe Django 1.6, all we have to do is just extend the custom user model, add the user preferences, the favorite color to the pet's name, to the relationship status, everything. I've seen this quite a lot, which is exactly what the documentation tells us not to do. The user model is just for authentication and nothing else. So when you're actually extending it or creating a custom user model, it should be for a very good reason. It should be because you don't have the defaults which are mentioned in the authentication. For example, you would like to use email as a user instead of the username as the login for that particular user. So in such cases, we actually should use a custom user model. And some people, I mean, this problem or this pattern has been seen ever since the first version of Django was released. So there have been a lot of solutions online and this is another problem with design patterns. So if you ask what is the right way to do X in Django, the solution depends on what version you're using. So immediately you'll get the question, okay, which version of Django are you using? Are you using 1.6 or 1.7 or about to be released 1.8? So the answer actually varies based on which version of Django you're using. And there have been various solutions like concrete inheritance. So I don't know why people still use concrete inheritance or why it's still there in the documentation. For me, it's like an Indian KFC with Veg Burger. Nobody knows why it's there in the menu but it's there in the menu. So concrete inheritance is not really a good solution because it involves a lot of extra database lookups. And at the end of the day, you'll probably replace it anyway. So what is the recommended solution? The recommended solution is very simple. The documentation tells you what to do. Just create a user profile model with a one-to-one mapping with your user model. But that's all the documentation tells you. I mean, it doesn't tell you how to implement it or whatever problems you'll face in or whatever steps you'll face and actually implementing it. That's what we're going to talk about right now. So if you're talking in terms of steps, the most obvious step is to create a user profile model which has a one-to-one correspondence with your user model. Now, again, notice that we are using the auth user model setting from the settings. This is because the custom user model was introduced. And we're also going to say primary key equals true. This is strictly not required, but this prevents a lot of concurrency issues when using the PostgreSQL database. So it's a harmless thing. I recommend to put it in there. The next thing is how do you ensure that our user profile model Of course, the user profile model should be having all this extra stuff that you want to put in your users like what is your favorite color or what is their profile information, address, etc. Next thing is to ensure that there is always a user profile created whenever a user is added or created. So the easiest way to do this is using signals. So just handle the post-save signal here. As you can see, that should be the creator. As you can see, there is a created flag as to that particular signal handler. So if it is not created, then obviously there should be something already there. But if it is already, if it is being created, make sure that there is a profile model being created corresponding to that user. So if you notice this code, you'll notice that I'm not actually passing any extra arguments while creating that. So this is a very typical use case. So what I would say is that if you are actually creating this profile model, make sure that the profile model has nullable fields or default values. So this is very important. So most probably your profile will be one user as a parameter, as a keyword argument. And all the remaining values will have to be some kind of default values or nullable values. Next, we are going to use a new feature in Django 1.7, which is called App Initialization Refactor. So every time a signal was used in Django, most people were not sure where to put that signal handling code. Some people used to say put in the init file. Some people used to say put in their models. Put it anywhere. We don't care. But now we have a real place to put it. That's called config. Now, all you have to do when you create an app is make sure that there is an init.py which specifies where the app config is. Once you have this app config, you generally call it app.py. You define this app config. And inside this app config, you will be given an opportunity to initialize whatever initialization code you need for that particular app. You can use the ready function and override that as a method. So I would say I would recommend putting your signal handling code over here. Now, there are a couple of optional stuff that you can make the life easier for your admin. For example, many people prefer to change their default admin editing code for the context mixing to populate the context and simply find out what template it is and renders that template. It becomes so easy because it is leveraging. Now, what is mixed actually? Mixing is actually multiple inheritance. Which is not found in many other languages, right? Python is unique in that sense that we have multiple inheritance. But many people ask this question, isn't there an adage saying that composition should be favored in terms of inheritance? I would say it is true, but actually you get the best of both worlds because even though mix-ins are technically inheritance, you actually are able to use the features of composition because if you look at template view, it's a derived class. It's actually a type of view, but it's also getting all the compositional advantages of aggregating all the methods and attributes into one single class. So it's actually the crisp example of how you can compose as well as inherit without having the disadvantages of both. The reason I explain more about this is because it's not just in views. Django uses mix-ins also in models, forms, what have you not. So it's kind of like a must-go kind of an implementation right now. Coming back to context enhancer pattern, so several views, like I said, need to use the same query set over and over again, or some variable which has to be defined in various templates just because you are going to reuse that same thing again and again. The recommended view of you doing this is overriding the get-context data because context mix-in is used for most of the generic views, but you can't do this everywhere. You can't copy paste it everywhere. It's not just dry enough. What I would recommend is to use a view mix-in. Now, view mix-in actually does the same thing, but it can be inherited. So if you can use the get-context data, if you have a public feed variable which needs to be there in every view, just define it, just call the superclass first and just define that particular variable and return that context. Now, all you have to do is whichever view you need this particular feed, you just have to derive feed mix-in and add that to your base classes. So the way you MRO or method resolution order is the most confusing bit of using a mix-in, but it's actually quite easy. Just include your mix-in at the beginning and just put your base class at the end and you're all set. So people who are fans of Monty Python might recognize this. There are people who actually create websites which, I mean, this is a very common requirement in which there are views which should be public. There are views which should be accessible for particular users and unlike the night you need to access, you need to let people give access. So things have changed in the world of Django when it comes to class-based views. The previous implementation was to use a decorator. Most of us are familiar with this decorator log-in required. You just use that for a function-based view. You just wrap the entire function in a decorator, but this is not very nuanced. What happens in a decorator is it takes a function, it just wraps that function inside and it's able to do something before a function is called and after a function is called. It's not able to do anything in between. But it's a little more nuanced when it comes to mix-ins. You can actually use something called a method decorator, which actually is invoked for a particular method. And in the case of log-in required, this is the equivalent code for class-based views. You can actually use, you can wrap this patch for method-based decorator. And all you have to do is derive from this particular thing. So all these kind of design patterns are incorporated in a package called Django braces. Many of us are familiar with this. Django braces actually has a built-in log-in required mix-in. So you don't have to reinvent the wheel every time. Now we come to very simple patterns which are common in templates, surprisingly less used. So some of us who are coming from the PHP world or any other templating language are familiar with how we actually use certain commonly, reuse commonly required pieces of a website when it comes to HTML, right? For example, the navigation menu, the sidebar, the footer, all these things are commonly, I mean, they are repeated across pages. In other templating language, what we typically do is called the include syntax in which we actually include pieces of code which are reused across. But Django uses a slightly different model which is similar to the way you inherit from classes. You actually form a base class or a base template from which other templates are derived and you can actually do this to the end-level, right? You can actually think of certain pages in a particular section having a certain design or a certain structure. And you can override the base template to create a new base template and that base template could be the base for all the other pages in that particular section. So the way I would like to look at it is it forms a simple tree so strictly it does not have to become a tree and that's why I named this pattern as the template inheritance pattern. So this is quite simple to understand. You create a base template or a base HTML which has a lot of placeholders in it. And these placeholders are nothing but block statements and these block statements could have some default values inside them. Now when you derive or extend from this base template all you have to do is mention which blocks you are going to override and what content needs to go into each of these things. And very simply you are getting the entire base structure for free and all you have to do is customize what actual content goes into that. Another common template design pattern you see is the active link. So as you notice in any menu or navigation bar the user should not get lost. They need to know where they are at any point in time. So that particular location is actually highlighted. So here you can see that the user is in the home page because the home is highlighted. This is very easily done using an active class added to that particular link. But how do we implement this in Django? There are surprisingly lot of ways to do this including custom tags and all that. But a very simple way to do this just using templates is to use the include syntax. So you have something called the include and the snippet. So here nab underscore is the naming convention that some people use for snippets. underscore nabbar.htm is there. And you just mention what active link is being used here. So here we are in the second link. So we call active link and set it to a value of link 2. Now the snippet is becoming very simple. All you have to do is you have a series of statements which check whether that particular active link is set to a particular value. If it is set to that particular value just use that link. Now custom tags are also a good way of implementing this but I find it much more easier to use this particular template only solution. So this is just we are just barely scratched the surface. I mean there are lots and lots of templates out design patterns out there and it's quite interesting to think about design patterns as something that you yourself can develop rather than something like a sacred set or a classic set of patterns that you should always follow. So my advice about patterns is it's very easy to overuse them. So I'd like to include how not to use patterns. So one thing is you should not think that you know using a pattern makes me cooler as some architects think. So I should just blindly apply template pattern, that singleton pattern etc etc. Just don't blindly apply the pattern. Every pattern comes with a problem statement, the context. The context is very important. Next we don't apply a pattern if your language supports a direct solution right. So like I said Python has a lot of features that are not there in certain other languages or it's a dynamic typing language so you don't really need to create classes just because a particular function accepts only a particular type of class. There is no typing when it comes to what a function accepts. So just be loose about it. Just follow idiomatic Python or the Zen of Python. Third thing is don't try to retrofit everything in terms of patterns as I just said and finally don't be afraid to create new patterns. Patterns are something that you should share, something that you should create. Finally I would like to say that design patterns are not visible to end users like I said in the beginning of the talk but it is something that you'll be always worried about or something that you'll actually try to seek actively. And don't try to learn patterns the hard way right. So most people try to break their head until they figure out what is the best solution and this is actually the worst thing that can happen to you. Try to study what existing design patterns are and your implementation automatically becomes better. In fact when I read someone's code I find that some pattern has been elegantly implemented. I can actually say that that guy is an experienced developer. I mean he has actually gone through a lot of struggle to actually reach this point where he actually implements or understands that particular design pattern. So try to learn more about it, try to understand what patterns are and soon you'll be finding yourself looking at patterns everywhere discovering patterns and understanding them and creating more beautiful and elegant code. And ultimately it leads to a successful open source project as well like Django uses all these design patterns to create a much more readable and elegant code. So that's all I had questions. Thank you. I think one of the volunteers would come to you. Just raise your hands if you have a question. Questions? So if you rise at the back you can come to the mic there or is there someone from this who I could possibly. There is a mic over there as well. My name is Sanjay. Just a quick question around the user profile thing. I just want to understand now that we can do the extend custom user profiles. Just the reasoning behind not putting relationship status in like why would you still create a separate user profile model? Can you just explain the reasoning behind it? I know you said it's not recommended but can you explain why? Yeah, it's basically to do with separation of concerns. So I think everyone actually when they start their Django project has the user profile built in. I mean the user built in it comes free with Django. But what is the purpose of a user model? The purpose is purely authentication. It's just to ensure that that particular user has the bare necessary details just to ensure that that person can log in to that site or use an authentication mechanism to get into that site. Now this is of course a stylistic advice. If you find that there is more than one line necessary to describe what a model does, then probably we're doing a lot inside that model. So when you say that a user model is being used for authentication and user profile and something else, it means that probably you should think about refactoring that particular model into more separation of concerns. So user profile pattern is basically to separate that neatly. In case you have anything that is related to a user's profile you just have to climb from request to request.user to profile or something that is in the user context. Basically a design advice. Okay, fair enough. Thanks. Hi, my name is Raj Kumar. I'm from mechanical engineering. So I'm completely out of all these field but I started Django last year when I got interested on the web publication design. So when I get into this template design that is implemented in Django is it something that I should consider libraries like Jinja2 as a design pattern for the Django template? Or how should I see these two things? Because people online whatever I see they talk bad about Django template and they recommend Jinja2. So how should I see this? Yeah, Jinja2 is not a pattern so to speak. It's a different implementation of a templating language and the reason why people talk bad about it is the Django template language which comes built in with Django has some performance issues. Performance issues in the sense it becomes almost a one to two comparison when you talk about Jinja. And another reason is because it's a very strict templating language. It does not allow you to include Python code in it. So any kind of logic or any kind of Python programming you cannot do inside templates by design. It's very intentionally kept out of the templating language. So a very common thing which people find comfortable to do is you know put all that business logic into templates. So only when you come to that point which still I do not agree with personally I feel that templates should not have any kind of programming logic inside it. It's only when you come to these two reasons like performance and programming allowed inside templates that you can replace it. And again replacing it with Jinja is very easy. You can probably use Django Jinja package or any third party implementation. It's very easy to replace it also. So it's only for these two reasons not necessarily for any functionality or business logic related. Does this performance come with the concurrent users? No. It's nothing to do with that. It's mainly it's something like the way it is compiled it's almost like running pure Python. So Jinja converts it into nearly pure Python while the implementation of Django templates is something similar to regular expressions. So it's a slight speed up because it's running pure Python code in Jinja. That's all. Thank you. So we have a bit short in time so you can catch him later. So Thank you. Thank you. Thank you.