 I'm very glad to see you here. And I hope you enjoyed my talk. Today I want to speak about hidden games in Django Country Padmin Library. This is a long series of talks. I start to speak about it in 2021. And yeah, it is my fifth or sixth talk about Django Country Padmin. I work, who am? I don't know. I am Maxim Danilev. I work like a software developer around 25 years. And last nine years, I work with Python and with Django. And last eight years, I work exactly with Django Country Padmin. Four years ago, I started to work also with Vue.js and Nux.js. And I have a serious talks also how Vue.js works with Django together. OK, all examples you can find in Repository. All my talks you can find in Repository. And links to other video talks you can find in Repository. Before I start, I want to say special thanks for my previous team. Anastasia always created for me design of presentation. Pavel Pelikin implemented all my crazy idea. And Martina Henreina tested it. Folks, I miss you, but something happens. And we try to see what happens in future. Also, special thanks for my family. Thank you for my wife, who support me. Thank you for my children. They await me at home. And thank you for my animals, Marcel and Kisa. And thank you for companies who support me on this conference. Nobody is here. And yeah, I don't know who appears here on the next talks. OK, basic steps. Before we start to use Django-Contribute Admin, we should create a models. Are you know about models in Django? Who knows about models in Django? Thank you. Thank you. In this case, I create two free models. I create a shop. I create model product. And I create model image. Every shop can contain many products. And every shop and every product can contain many images. This is only models. Till this moment, Django-Contribute Admin not works. Before, we should create a model admins. I have created a model admin for a shop, model admin for a product, and some inlines. I know about inlines in model admin. Inlines has a possibility to change some binded objects in form, in change form from parent objects. I show a little bit later how it works. If you start your project, or example project for repository, you can see ad form for change data form shop. You can change title. You can change description. And also, in the same time, you can add some products to shop. And in the same time, you can add some images to shop. Good or not, I cannot say. But this possibility at some products and at some images is exactly inlines. We have inlines form in parent form. OK. In this talk, I compile knowledge about creating user-friendly and developer-friendly admin panel based on the Django-Contribute Admin model. At first, we should to register site admin. But we should not register site admin. We should register site admin config in our settings API to start to work with Django-Contribute Admin model. And in documentation, you can find this example. For my opinion, we can do something better than in documentation. And my offer to you to create application which I call admins. And I register this admins application like normal. Why we should to do it normally? Because we can contain readability. We can achieve readability in our settings API. Everybody who works with settings API can remember how huge this text can be. And that's why I try to contain readability from scratch. And this is the only possibility. You can do all what you want in Django. I offer you to do something better on my opinion. And after that, we should to register admin URLs. Also, in documentation, you can find example. We register admin URLs if I work with paradigms multiple admin sites. I should register. I should with hand write every URL in URLs API. I think this is also not good. Why? Because we can made it automatically. In Django, we contain one container which knows about every admin site. And after that, I ask from container all admin sites. And I take name from every admin site. And I register these URLs automatically. And after that, for me, it's don't matter how many multiple admin site I have. I have always only one line in URLs API. And this all happens automatically. If I create new admin URL, it comes automatically. And of course, for me, it is better. What I mean about multiple admin URLs? This multiple admin paradigm helped me to register some model admins only on the one admin site. This other URL, I can register other model admin. And after that, I can protect this URL group by permission for user. For example, my translation can achieve only translation admin site. My content manager can achieve only content admin site. That's all. Sometimes finance manager or tax manager should go only to sales. And I can give them only one permission. You can achieve this admin site or not. It's much, much, much better than to work with permission on one admin site with a whole list of model admins. Who has more than 100 model admins on the admin site? And this is a possibility to split it on many, many admin site and work easily. OK, but again, I like automate all in Django. Django is funny. Django helped me fly fast and with fun. But sometimes, Django offer me to make something unimportant. For example, I should register model admin. This is a standard example. I should import models. I should create model admins. And I should register appropriately model with appropriately model admin. Too much work for me, exactly. What I want to do, I create model admin auto register. And after that, you don't need to read this quote. You can see it in the repository. But what happens? After that, I create admin PI. I write only model admins. And on start of my server, auto register goes through full models, goes through full admins. And appropriate model is registered with appropriate model admin. It's easy. And I offer you. If you try to do it one time, you cannot forget about it. Every time I put this quote in every new project, because it's amazing, easy to work. Next step, model admin ordering. I don't know why creator of this element put some logic against humanity. I don't know. I cannot answer why this application and these models came in this order. I know. Of course. It's alphabetically order. But sometimes I want to set up myself. I want to decide myself in which order it should come. And I can change it only with one line. I should have a write get up list from admin side, from every admin side. I made it like a mixing. And after that, I can change order of application appropriately order how I register my apps in set up pay. And after that, order of model admins is exactly the same order how I define classes in models. It means I can swap a shop and image. And image comes on the first place. Shop comes on the second place. It's so easy. It's so nice. Try to do it. Of course, after that, you understand what I mean. Janga can be more easy, more funny. And I like Janga, sorry. I mean, we can take control of our project back. Not from, we can take control from Janga developers and they can take it in our hands. OK, the big problem about this problem I tell many times. Every model admin is singleton. I know what means singleton. It means we have always in our project only one instance of model admin. Why is this problem? If I compare model admin and generic class-based views paradigm from Janga, generic class-based views paradigm is on the bottom of screen. In this paradigm, on every request, we create a new instance of view. In model admin, we don't create any instances. It was created on the server start. Problem is, I cannot use these instance like a data container. I cannot store some results in this data container because if other user works in the same time with the same instance, they can overwrite my data. This is a problem. But also, if I solve this problem, also we can increase speed. But some computation happens many times on one request. I have a talk there where I can show nine times calls one method, four times calls other method. I can cache these computation results. And how I can solve it? Solutions is easy, only four lines. On every request, entry point is admin view on every admin side. On every request, I take this singleton instance, I create the copy of this instance, and I call appropriate method of new instance. And this is easy, and it works. And every time on every request, right now, I have the new instance of model admin. We create this solution on Django 1.3, and after that, always we put this patch in our projects. What we can achieve? If I store computations results in cache, I can cache it in data container. We can increase, we can win around 20% of response time. 20% is already say something, but I can increase more, I can win more time if I do something else. But try to use it. I write some articles about it in the internet. If you don't understand what I mean, you can try to read it in an article probably there. You can understand better. OK, next element, Django admin actions. For my opinion in Django country admin, Django admin actions, this is the best feature in full library. What I mean? Django admin actions help me to change many objects in one time. Model admin give me interface, crude interface to work with one object. Model admin actions give me interface to change many objects in one time. But sometime I want to work with actions in generic class with view paradigm. Django offer us only functional based view paradigm in actions. How can I do something? Of course I can. I create a mixing which only patch view class from generic class based view. And this mixing help me to convert every model admin action in generic class based views action. Why I need it? At first, I can create action in this action. I can set up some attributes and I can create process. I can create child action from this action. I can override only process or I can override only some attributes. And this is much flexible than works with functions. Try it and you also cannot forget this technology for model admin. I like it. But I should say warning, please don't use default action decorator from Django. This decorator not safety. I already tell it on the other talk. And this decorator cannot work with user permission, like for example, standard permission required decorator from Django. I offer you simply to avoid this decorator. I think it should be overridden in Django core, in Django country admin. Sorry. Varning, how we can work with permission for actions, we can simply override this method from model admin class and after that this all works. You can use it. For example, one permission, change quantity for products can use, this action can use only stock manager. And I give this permission and only stock manager can call this action. It's important and flexible. OK, and we go to middle of my talk. And important thing, who knows about admin API in Django? By default, we have only two. Admin API, SSI 18th N, internalization API, and autocomplete view. But sometimes I see many libraries which create a new API for crude interfaces for backend admin and after that they create their own reactive backend. But why do they need to write this API? They already exist in Django. What I mean, only what I need from Django, I want to receive on every request instead of template response. I want to receive JSON response. How it happens, it's easy. The same view which I already overridden before, in this view I catch every template response answer. Template is not rendered yet and I take only context from template response. And I jsonize this context like a JSON answer. That's all. And in this moment, with two lines of code, I achieve full crude APIs for full model admins in my project. I don't need any Django REST framework for that. Of course, I have here one trick. I use standard Django serializer. I overrided it as my JSON encoder. I like to write, I like to use Django instead of other libraries. And in Django, we have also serializer possibility. And I use Django serializer possibility in this solution. OK. This is a standard answer from example. You can start, you can see it. And you receive the full information which you need to render template. Or you can use this information on the front end to create some flexible back end front end for your manager. OK, I only offer you don't write new crude admin API. They already exist. But sometimes people want to create something Q because they cannot find it in the existing library. OK, in the middle of my talk, all features which I already tell, you can find on the video. And repository and go on. And we go right in my talk. Model admin get fields, have an bug. Probably you should know about it. I create my model title and slug. I create two model admin. In one model admin, I declare fields like a fields attribute. In other model admin, I declare fields like a field set attribute. And if I call model admin get fields, for first model admin, I receive a title. For second model admin, I receive title and slug. It means get fields not works normally in Django. And this not solved yet. And right now we go to deeper in Django admin, flowable inlines. Sometime you can see change form appears. And after that we have some inlines. But what if I want to put one inline somewhere in middle of admin form? I know many solution. They override templates. I don't know something else. But in reality, it's only two lines of code. I create my read-only field. And on the render of this read-only field, I take from context inline. And I render this inline on the read-only field. That's all. I take from context inline. And I put this inline instead of read-only field. But if I go deeper in this idea, what if I want to take some inline from other model admin and put this inline in place on read-only field? This is nested inlines, which already achievable from Django 1.3. But nobody knows about it. Only four lines of code. But we have find it works right now. You can use it. But we have some bugs, exactly bugs, in standard inline.js in default Django. And my team, we have completely overridden this inline.js. You can use it from repository. Don't matter. I want to use nested inlines or not. My inline.js already removes some bugs from old inline.js. OK. Many-to-many truth model, one idea. If I use truth model in Django, custom truth model for many-to-many, I cannot change it in model admin. I receive an error, but not for me. If I use instead of standard model, if I only change one attribute in meta, auto-created, I add this attribute in meta, automatically it works. But please, avoid it if you don't understand how it works. But it can be painful in future. We use it already three years, this possibility. OK. Once possibilities, I want to say, OK, the first. In model admin form, we have related widget wrapper. If I have some object from our table, appears some icons, special icons. Sorry, this widget is hard-coded in Django admin. And I want to throw away some icons, how I can do it. You can see on the video my investigation and offers. But the best solution we can say for widget. Please, can view related files attribute, and after that, the view possibility disappears. This is easy, but we go deeper and related fields with autocomplete. Autocomplete already exists in Django from 2.0, but we don't have many documentation about it. And it's easy to set up. But sometimes it works. But sometimes I want to see from land United States of America only region for United States of America, dependent fields. How I can change it? It's easy. It works like a charm. You can see it, United Kingdom. How it works? Of course, with autocomplete. I should only override getSearchResult in child model admin, and I should give information for parent select, which child select should be changed. And it works. We created for that small search JS script. But very important, we have found some bugs in autocomplete.js, default autocomplete.js in Django. And my team, we have overridden these autocomplete.js and removed some bugs. It's also in the repository. OK, last idea, which I want to say today. Model admin form, object state versioning. We have many libraries which help me to keep version of object state. Who ever seen this stupid construction? I have created it. But we should not do it. Why? We can use log entry, sorry, error, not item, log entry. Django country admin write on every state changes the information about state. The last row, action time from last row, this is change time. The action time from first row for this object, this is creation time. User from the last row is the last editor. Creator from the first row is creator. And if I use subquery, I can create only one asking database, and it works like a charm right now. You can see. For example, the last state changes happens in Yuli for this product object. And we can state changes use for form safe. How? Simply, I use this data stamp like a versioning. And on the safe, I check last stamp like a version number. It works. You can use it and summary from my talk. If you want to write something, probably, it already exists in Django. If you are a Django programmer, try to work with Django, not with Python. And try to learn Django. Don't matter. Have your documentation or not. Make Django not bar. Thank you.