DEV Community: Maxim Danilov

Django Nested Inline. Save Data.

Maxim Danilov — Wed, 31 Aug 2022 17:26:43 +0000

This article is part 2 in a 3-part series on creating nested inlines in the Django admin panel.

Nested inline rendering. This article is about rendering a Nested Inline. At the end we should see a Nested Inline in our ModelAdmin. But this Nested Inline can not save own data yet.
Django nested inline. Save data.
The second article shows integration of Nested-inlines in the ModelAdmin to make saving data possible.
Django nested inline. Javascript.
The final article in the series explains how to override the inlines.js in Django package to make it possible to add/remove Nested Inlines on fly in the ModelAdmin.

On the journey to a working nested inline in this article I will touch on the issues of form prefixes, validating a custom field, saving a custom field and form encoding's problem.

If you are want a quick code example click here.

Form prefixes

First, we need to handle the form prefixes so that our data is sent in the correct form.

Djangos inline has a prefix associated with it, each new line gets its own id, set as follows prefix-*index*. I thought a reasonable solution for nested-inline would be to handle the prefix of the nested-forms as follows:

parentPrefix_parentIndex_childPrefix-childIndex

In the end it should resemple this stucture:

>ParentPrefix-0
>>ParentPrefix_0_ChildPrefix-0
>>ParentPrefix_0_ChildPrefix-1

>ParentPrefix-1
>>ParentPrefix_1_ChildPrefix-0
>>ParentPrefix_1_ChildPrefix-1

We update the inline-formset prefix with the prefix of the parent form. This can be done in the image_inline method, but first we need to get the prefix of the parent form from somewhere. We can set the form attribute in instance inside the __init__ method of that form itself.

So we get the 'prefix' from the parent form to generate the 'prefix' of the child forms.

Data validation

Django handles validation of the main form and its own inlines on its own, but validation of nested inlines is not yet supported.

Since validation happens in ModelForm, we need to look there to implement validation for our nested-inlines.

While I was trying different methods, I realized that it would be much easier to implement the nested-inline itself in the form as follows.

We see that inside the is_valid method calls self.nested.formset.is_valid(). Self.nested is an attribute that keeps the link to the nested inline.

First is created an instance of *Product*ModelAdmin.
After that, the _create_formsets method is called. This method returns the corresponding form sets and their instances depending on whether change_view or add_view was requested.
After get_inline_formsets returns the nested inlines of that form.
At the end the prefix is handled and the finished inline is returned.

We set the request attribute of ShopModelAdmin in the render_change_form method before. Now, that's not enough. If we want to have the request attribute for both GET and POST requests, we need to set the attribute in changeform_view, because this method is called earlier and is independent of the method of request.

Now that the nested inline is processed in the form, we can shorten the code of the original image_inline method.

save method

Let's wrap the save_form method of ShopModelAdmin to also save nested-inlines.

A form calls its save method only when 2 conditions are met.

form.is_valid() must be True.
form.has_changed() must be True. We've already handled the is_valid method. Now we need to change the has_changed method. It should check if our nested data has changed. We also need to specify, which fields have changed so that the form can save the changed data in the model.

Fortunately, we can do everything in one changed_data property.

Of course it should be a on-line generator and not the two for's

Since our nested-inline is defined as a read-only field, the changed_data property will nominally ignore all changes in nested-inline, so we need to add the modified fields of nested- inline to the other modified fields.

Right now we have a working nested-inline for most Use-cases. But I discovered an exception. If our nested-inline contain any FileField, the request.POST processing breaks. It took me a long time to figure out, why it worked with other fields and not with the FileField. The answer lies in the attribute enctype="" of the HTML-form.

Form encoding

There are two types of enctype attribute values for our purposes:

"application/x-www-form-urlencoded"
"multipart/form-data"

This attribute determines how the browser sends the HTML form data.

The application/x-www-form-urlencoded enctype creates a simple long string of name and value pairs. These pairs are separated by &, and the name and value are separated by =.

The multipart/form-data enctype define a 'delimeter' in the Conent-Type header. Each pair of values is separated by this boundary formatted as: --<boundary_value>. Then comes Content-Disposition: form-data; name="<field_name>". After that, the value of the field is set. After that comes another boundary.
Final -- closes the body of the query.

It is not possible to send files with the application/x-www-form-urlencoded. This enctype is best used for most web forms with short alphanumeric values.

The multipart/form-data, as already mentioned, is used when we want to send files of any type.

But why do we need two arts of enctypes for HTML forms?

The answer lies in the speed and size of the request. The request without data with application/x-www-form-urlencoded enctype is about 6 times faster and incredibly smaller than the same request in multipart/form-data enctype.

Why is this important for our nested-inline? If we have a FileField in a nested-inline, by default the form does not recognize it, because we have nested-inline as a read-only field. This means that the nested-inline will not send the content of the FileField. The other fields will be handled normally.

To fix this, we need to wrap the is_multiform method of our form so that it also calls the is_multiform method of the nested inline.

Why not use multipart/form-data enctype all the time? Yes, you can do that, and it will work. But the query size increases significantly with each field you add to the form. That's just unnecessary overhead.

For more information on the encoding of HTML forms I would recommend this article about it and this discussion on Stackoverflow.

Limitations

This implementation of nested inlines is not without its flaws. This is just an example of how to approach creating nested inlines.

With a little more time and determination, it is possible to implement general inline support in the Django-inlines themselves, which would make creating nested-inlines pretty easy.

In this solution, we assume that an inline is already defined in ProductModelAdmin. But that may not be the case. We can add a check to see if ModelAdmin has an inline.

Multiple inlines with multiple nested.inlines are not implemented in this solution. The nested method returns only the first inline from ProducModelAdmin. This is solvable by returning a list of all ModelAdmin inlines.

As you can see, this is not the final answer to the question of creating nested inlines, but this is the working solution that you can use in your projects.

Saving data is now possible in a nested inline, but you may notice that it still cannot be used in the django admin panel. This is a result of the mess the django developers created in inline.js.

We'll solve this problem in the next article.

Written by Martin Achenrainer

PS: I would like to thank Maxim Danilov for his extensive help on this series of articles, he was the inspiration and led me to this clever solution. I would also like to thank him and his company wP soft for giving me the opportunity to develop and improve my programming skills in a working environment.

Django nested inline redering

Maxim Danilov — Fri, 24 Jun 2022 09:26:41 +0000

This article expands on the ideas of my previous articles:
Django admin dynamic Inline positioning and How to solve the singleton problem in Django ModelAdmin.

This is also the first part of a three-part series on how to get Nested Inlines in the Django admin panel.

Django Nested Inline. Rendering.
This article is about rendering a Nested Inline. At the end we should see a Nested Inline in our ModelAdmin. But this Nested Inline can not save own data yet.
Django nested inline. Save data.
The second article shows integration of nested inlines in the ModelAdmin to make saving data possible.
Django nested inline. Javascript.
The final article in the series explains how to override the inlines.js in Django package to make it possible to add/remove Nested Inlines on fly in the ModelAdmin.

Although you will hopefully not need to implement nested-inlines at present, you can learn a thing or two about Django.

If you are want a quick code example click here.

Introspection of existed Nested Inline packages

The direct way to get Nested Inlines in Django Admin would be to install the package, since surely someone has already solved this problem, right?

After a quick search, you come across Django-Nested-Inline and think you're done.
Unfortunately, this solution has some problems and does not work properly.

For example, it doesn't allow synchronous editing of objects at the same time. I mean - if several people are working with your Admin Panel at the same time, there will be unexplainable errors all the time. The probability of such errors grows exponentially with each manager and each nested Inline.

So we can try to create our own Nested Inline. It's not complicated.

Basic Nested Inline rendering

First create a shop model, a product model and an image model. The product model must relate to the shop model, and the image model must relate to the product model.

Something like this:

Now we create some basic ModelAdmins with Inlines, like this:

Let's make some changes to ProductModelAdmin and ShopModelAdmin. We need to set the request and response as attributes for both ModelAdmin.

Experienced Django developers may notice that using a ModelAdmin instance as a container is not threadsave, and they would be correct if it were the default admin panel.
Here I refer them back to my previous article to explain how this works.

This is one of the cornerstones of how to create nested Inlines.

Additionally we should override the get_inline_instances method of ShopModelAdmin to set the modeladmin inline attribute to the current admin instance, this will be useful later.

I have made this function as generator, it calculated only when the result used for iteration.

We can now take the idea of dynamic inline positioning and develop it further. If it's possible to use inline in ModelAdmin as a field, it should be possible to do the same in inline itself, so let's copy the ProductModelAdmin code from that article.

But not everything works the same as in the ModelAdmin.

First, we can not get the context from the self.response attribute because the inline does not have that attribute.
But the Inline has the attribute modeladmin because we defined it in get_inline_instances. inline.modeladmin is the ModelAdmin instance. That has a request and a response attribute. So we can get the context from there.



context = getattr(self.modeladmin.response, 'context_data', None) or {}

Secondly, Context does not contain the Information about Nested inline. With the code above we want to display a nested inline in the field of the current inline. We can call the view method for ProductModelAdmin and extract a nested inline from response. There is inline that must be nested.



admin_response = ProductModelAdmin(self.model, self.modeladmin.admin_site).add_view(self.modeladmin.request)

inline = admin_response.context_data['inline_admin_formsets'][0]

Although it should be noted that this is not the final version: in reality we need to call the appropriate ModelAdmin view as requested, rather than just add_view.

Thirdly, we need to modify the args we pass to the render method so, that they contain an updated context that includes our extracted nested inline, and request.



return get_template(inline.opts.template).render(context | {'inline_admin_formset': inline}, self.modeladmin.request)

In this construction we don't change context variable directly. The update operator ('|') creates a copy of the dictionary and updates it with the new values.

The final method should look like this:

If we start our project and try add a new shop model we see our nested inline.

As you can see, our nested inline is displayed. Yay! But you might also notice that there are some problems rendering the inlines. This is because Djangos inlines.js for inlines is a complete mess and needs to be refactored. My issue about it in djangoproject was rejected as "ivalid".

Fortunately, I will show, how to do this in last article of this series.

At the moment, this display error can be temporarily fixed by changing one line of code in the django\contrib\admin\static\admin\js\inlines.js file.



// row 335:
$(selector).stackedFormset(selector, inlineOptions.options);

// change to:

$(this).find("[id^=" + inlineOptions.name.substring(1) + "-]").stackedFormset(selector, inlineOptions.options);

Not it works better than before.

Now it's not perfect, and the rendering problem still exists.

This article was only about getting the nested inline before the first render, without validation and saving data of nested Inline. In the next article I will show how to save the data properly.

This article war Written by Martin Achenrainer. I thank Martin, for translating and assisting with this English article. This idea was first presented in September 2021 at PyCon RU

Some words from Martin:

I would like to thank Maxim Danilov for his extensive help on this series of articles, he was the inspiration and led me to this clever solution. I would also like to thank him and his company wP Soft for giving me the opportunity to develop and improve my programming skills in learning by doing.

Autoregister Django ModelAdmins

Maxim Danilov — Tue, 07 Jun 2022 10:25:40 +0000

Some time ago I discovered that Django has the ability to auto-register ModelAdmins. Since this is not common knowledge and carries a number of benefits, I decided to write an article about it to bring it to the attention of the Django community.

First, let's go over the basics of how to normally register ModelAdmin.

Standard `ModelAdmin` registration

To register ModelAdmin, we first create a model

Next you need to create a ModelAdmin and register it with the model on the SiteAdmin.

Now let's run our dev server and see if it worked.

But what are these? Some additional ModelAdmins are registered, but we've never defined them. This means Django is auto-registering these standard ModelAdmins somewhere.

Django `ModelAdmins` integrated auto-register.

After some digging in django.contrib.admin.apps, I found that these ModelAdmins are registered in the ready method of the AdminConfig class.

class AdminConfig(SimpleAdminConfig):
    """The default AppConfig for admin which does autodiscovery."""

    default = True

    def ready(self):
        super().ready()
        self.module.autodiscover()

We can use this fact to our advantage if we wrap this method not only for auto-registering the standard Django models, but also for our own.

We can do this as follows:

We go through all AppConfigs in our project and get the admin module from AppConfigs. Of course, this is the case if the admin module exists.
We then go through all models from this AppConfig.
There we check if the model has already been registered with SiteAdmin.

If not, we search for ModelAdmin class with name '*model_name*ModelAdmin' in the admin module. If no such class is defined, we use None.

Finally, we register the model using the found ModelAdminon SiteAdmin.

If ModelAdmin is not defined, the register method registers the model to ModelAdmin class by default.

But why should you do it this anyway?

Benefits

1. Shorter Code

With this approach to registering ModelAdmins you can multiple lines of code in one 10-line solution.

You can say goodbye to the empty ModelAdmin classes just to register the model, if you done it before.
No more @admin.register(model) wrappers on any ModelAdmin.
Most importantly, no more long import lists for your models in the module admin.

Depending on how many models you have and how many ModelAdmins need to be registered you can save a lot of lines of code.

2. Easier development

Continuing with the idea of the previous point, you no longer need to worry about registering ModelAdmin during development because everything happens automatically when the server starts up.

3. Circular Imports

With the current system with huge import lists in the admin module, it is not that difficult to get circular imports and find a workaround. With this solution, these import lists are gone and you no longer have to worry about models and circular import.

Variations

Sometimes you don't want register on the current SiteAdmin all of your models, so what do you do then?

Of course you can modify the solution above as you wish, but here I want to give you some ideas for solving the most common problems.

Register specific models only

If we want to register only the required models with ModelAdmins, we can define only the required ModelAdmins in the admin module and do the following:

In this solution you need to add in the admin module **ModelName**ModelAdmin class for each required model.

Alternatively you can add a flag to the model if it should be auto-registered.

Remove standard registered models

Perhaps you don't need the standard Django models registered in your project. You can remove them with one simple line added to the ready method.

These are just some of the options for using Django autoregister. I'm sure you can think of other clever ways to use it, and I hope this article was useful.

I thank Martin Achenrainer, who is an apprentice at my firm, for translating and assisting with the English article. The idea was first presented in September 2021 at PyCon RU

Some words from Martin Achenrainer.

I would like to thank Maxim Danilov and his company wP soft for the opportunity to learn and improve my programming skills in the workplace.

How to solve the singleton problem in Django ModelAdmin.

Maxim Danilov — Tue, 03 May 2022 16:20:29 +0000

The ModelAdmin class from django.contrib.admin.options has a bad design from the beginning: every registered ModelAdmin in your project is a singleton.

This fact creates a big barrier for every developer who uses Django Admin in his project. This slows down the project, creates problems when the same ModelAdmin is used by several users, and encourages programmers to use hacks to get around the limitations of this (anti) pattern. You can learn how to solve this problem in 5 lines in this article.

Why the developers of django.contrib.admin continue to rely on this architecture is a mystery to me.

Luckily there has been a quick and easy fix for this issue that works from the first version of Django up to the current one (4.0.3 in april 2022).

Table of Content:

The problems. I will describe in detail the problems encountered when using the singleton architecture for ModelAdmin.
The solution. I will walk you through the fix and explain how and why it works.
Django devs. I'm asking Django developers reading this article to consider changing the django.contrib.admin structure to make life easier for everyone.
Talk from PyCon 2022 about this problem. In addition to this article I have a video about this topic from PyCon DE 2022 in Berlin.

The problems

1. Multiple users can not work normally with the same `ModelAdmin` at the same time.

When multiple users are running the admin panel at the same time, the singleton design pattern can allow one user to modify another user's data.

Let me demonstrate it with the code from my previous article about Django admin dynamic inline positioning. Right now it is not really important what the code does. We just modify the functions in the admin panel like this:

Now let's open the two tabs of the admin panel to simulate two users. Now let's open the change form for the product with pk=1 on the first tab (/admin/products/product/1/change). After this line, we are stopped by the breakpoint:

10            self.hello = 'hello this is the first obj'

If we check the self.hello attribute, we see the following:

Now let's open a change form for a product with pk=2 in another tab ('/admin/products/product/2/change') and see what happens. We get a response from the change form right away because we skipped the breakpoint. But let's see what happened to our hello attribute that we set for our ModelAdmin in the first tab.

Our ModelAdmin.hello attribute for GET request pk=1 has been changed to "this is the second obj", even though we did nothing in our first thread.

We proved that ModelAdmin is a singleton, which means that we always get the same instance of ModelAdmin.

This is a simple demonstration of the problem. Since there are no real consequences in this example, some might even consider it trivial, but the consequences of this behavior for our project could be dangerous.

With this behavior, every ModelAdmin's do not guarantee the integrity of the data, because it is impossible to trace who has edited the data. Did this current thread edit our data? Did another request change something without our knowledge? Who knows.

You might argue that this isn't a problem because the requests have to happen at the same time for this problem to take effect. However, in a project where multiple people are running the admin panel at the same time, the issue is not if someone opens ModelAdmin at the same time as someone else, but when.

This causes errors, for which there is no obvious explanation without an in-depth understanding of the admin panel architecture.

So the easiest way to avoid the problem is not to use the ModelAdmin instance as a container.

But not every developer is aware of this, and ModelAdmin is often used by inexperienced developers to store data.
In this example the highest voted answer does exactly that.

If we can't use ModelAdmin, then where can we store our data? Django does not give us a clear answer by default.

2. Hacks

Since you can't use an instance of ModelAdmin as a container, developers are looking for other options.

Most of the workarounds I've found are to store the information in a global dictionary and map it to the locals of current thread. Yes, that works, but shouldn't there be another way than that?

3. Speed

If it were possible to use ModelAdmin as a container for the data, Django itself could do it. Currently Django repeatedly calls certain ModelAdmin methods to get the same result during the same request. All of these results should be cached. If ModelAdmin behaved like Django-GCBV, we could save valuable computation time.

The table shows how often the following ModelAdmin methods are called several times per request:

	changelist GET	change GET	change POST	add GET	add POST	delete
`has_view_permission`		5	3	4	3
`has_module_permission`		3		3		3
`get_ordering`	2	3	3	4	3
`get_preserved_filters`	2	2	2	2
`has_change_permission`		9	4	4	4
`get_list_display`	2
`get_search_fields`	2
`get_model_perms`		3		3		3
`has_delete_permission`		4	3	4	3	3
`get_readonly_fields`		2		2
`get_search_results`
`has_add_permission`		4	3	6	3
`get_empty_value_display`	variable	variable		variable
`get_actions`	3
`_get_base_actions`

The number of calls to some methods depends on the number of AdminForm or ModelForm fields.

Let's compare the response time of the "vanilla" Django admin panel by default and the Django admin panel with cached method of ModelAdmin. As a code example I took the project from my last article:

I have created a middleware that outputs the time elapsed between the request and the response:

If the middleware code is executed, we will get the result:

default django admin panel	modified admin panel



average time: 0.031673s	average time: 0.026001s

As you can see, even in this simple project the speed increase, due to caching the results of calculating functions, is **almost 20%!

This speed can be greatly increased by refactoring the entire ModelAdmin class, since it is currently a bloated piece of spagetty-code.

The solution

Let's now take a look at where ModelAdmin singletons come from in Django and try to fix it.

Each instance of ModelAdmin is created when it is registered by instance of AdminSite from django.contrib.admin.sites.

In the docstring of the AdminSite class, we learn that the get_urls method is used to retrieve views from each registered instance of ModelAdmin. Thanks to the author of this docstring.

In the AdminSite.get_urls we can find this code snipped:

Here we see that the ModelAdmin.urls property is called.
This property returns the result of the ModelAdmin.get_urls method. So, let's explore what this method get_urls does:

At first glance it seems like a lot of code, but let's unpack it piece by piece. Let's start exploring this code from the bottom.

The returned list is created for url-dispatcher. It contains tuples from the url, the view to be called, and the name of the view.

What matters to us is, what is given as a view. This is a wrapped bounded method of a ModelAdmin instance. So, let's take a look at what this wrapper wrap does.

Fortunately, this wrapper wrap is defined right above.
The update_wrapper at the end of wrap is not very important, it just makes the final view behave like a ModelAdmin instance.

The body of the wrapper function is crucial for our mission. There we see a call of admin_site.admin_view with bounded method of ModelAdmin instance as an argument.
admin_site is the instance of AdminSite on which the ModelAdmin instance is registered.

This method we need to override to rid Django ModelAdmin of the curse of the singleton pattern.

Pffew, all these explanations are for one simple function that needs to be overridden. Yes, because without knowing how this whole system works, we wouldn't understand how to properly override this function to solve our problem and not break anything.

Let's create a child class of AdminSite and override the admin_view method like this:

Let's ignore all the wrappers and focus on these lines of code:

new_instance = type(instance)(instance.model, instance.admin_site)
return func.__func__(new_instance, *args, **kwargs)

func is a bounded method of our singleton instance of ModelAdmin, which is always the same for every query.

The __func__ attribute of func is a method of the ModelAdmin class. It is not more associated with any instance of ModelAdmin.

Here I am using python terminology bound and unbound method. func.__func__ is not bound to an instance of func.__self__, but it is also not a static function, it is a class method. An instance of the same class as func.__self__ is still required as the first argument to call this method.

To create a new instance of ModelAdmin we need model and admin_site as arguments, which can easily be taken from the old singleton-instance.

Now we can return 'func' call with new instance as self, and arguments *args and **kwargs, that are passed at the time of the call.

Now the Singleton architecture is successfully bypassed.

This means that every time a request is sent to the view a new ModelAdmin instance is created and it's corresponding view function is called

As mentioned earlier, it was possible to avoid all this agony from the beginning of Django.

All that remains is to make our child AdminSite as default in our project.

We can create a child of the AdminConfig class like this:

The default_site attribute must match your AdminSite class.

Finally, register AdminConfig in the settings.py in INSTALLED_APPS to complete the changes. Remember to remove the default admin panel.

This new admin panel in its current form is not faster than the old one. We still need to cache ModelAdmin methods. To do this, you can create a Mixin for ModelAdmin, and wrap the above methods as follows:

I haven't had any problems with this caching implementation, but if you're worried about multiple calls to the same method with different arguments, you can wrap the methods with memoize wrapper. This can also reduce the speedboost of our solution.

Conclusion

I love the Django Framework. It's a powerful tool that helps me create great things. I can fix any problem of this framework with just a small piece of code in the right place. But finding that place is not always easy. And Django's documentation can't help. This lack of documentation - This is Django's biggest problem.

Django devs

I hope that after the points I have laid out in this article, you will agree that there are serious problems with Django's implementation of the singleton architecture in the admin panel.
This pattern makes the admin panel experience cumbersome and slow, and something needs to be done to fix it. And I'm writing here how that can be done.

The fix I've proposed is an important first step to improving the Django admin panel, but unfortunately the next work begins after its implementation. The ModelAdmin class code needs to be greatly improved, i ask about it, for example, in this issue, but if it can be done, I'm sure the Django admin panel will be a better tool to work with.

The Singleton Problem talk at PyCon 2022

I have spoken about this problem at many events. You can see my video from PyCon DE in Berlin in April 2022, I wrote here that I will be speaking at that conference.

The Python and Django conferences you don't want to miss in 2022

Maxim Danilov — Sun, 10 Apr 2022 18:18:16 +0000

Quick reminder for those, who would like to broaden their horizons: there is “PyCon DE Berlin 2022 ” coming up already next week!

As an invited speaker I will cover three topics there:

On Monday 11.04. at 16:20, lightning talk about „Django ModelAdmin Singleton Problem“

In this talk I will briefly describe the main problems of the ModelAmin class from the
Django.contrib.admin.options module and solve this problem once and for all in 4 lines of code, summed up by the additional benefits of this solution.
Followed by "Django ModelAdmin autoregister on AdminSite" lightning talk on Tuesday April 12, 2022 at 16:20.

In this talk I'm going to present the ModelAmin autoregister on
AdminSite from Django.contrib.admin.sites module and how that should have been done originally. Alas, it's not implemented in django yet. I'll fix that in 5 lines of code. I will show you
how this solution will simplify code development, reduce the number of imports, and help you avoid possible circular dependencies.
On wednesday April 13 at 11:00 am, I will have a 30 minutes presentation named “Easy Python: lies, damned lies, and metaclasses”.

Here I describe the python's suitability for large projects (spoiler alert), bring up "software complexity problem" and talk about the many levels of abstraction that python has inbox. I will as well talk about how those abstraction levels can
both help and hinder large python projects.
I would appreciate you joining the discussion and sharing your opinion on these topics.

If you for some reason miss that one, the next conference is coming in September: DjangoCon Europe 2022 in Portugal.

I will make some expert talks and workshops there as well, including talk and workshop:
“Hidden Gems in Django.Contrib.Admin”, about effective Django SiteAdmin.

I'll unfold the hidden power of the django.contrib.admin module code, talk about it´s bugs in the code and of course some innovative fixing options.

The other planned talk and workshop is called “Creation of true Multilinguale Django Project”.

It's about creating a real multi-lingual Django project, its problems, architectural peculiarities and the difficulties of implementation. I will present a new version of the DJANGO-TOF library, which solves some of the essential problems.

In my opinion, expert talks at a Conference are not just the best way to present new ideas, but also the most efficient way to learn new things. It will be my pleasure to answer your questions and exchange opinions after the talks. Feel free to approach and contact me there and...

See you soon!

Django admin dynamic Inline positioning

Maxim Danilov — Tue, 05 Apr 2022 09:16:15 +0000

Recently I've received an interesting request from a client about one of our Django projects.
He asked if it would be possible to show an inline component above other fields in the Django admin panel.

At the beginning I thought, that there shouldn't be any issue with that.
Though there was no easy solution other then installing another battery to the project. My gut feeling told me, there were another way around that problem.

The first solution I found was from 2017. It had too much code for such a simple task.

Our executive lead programmer, Maxim Danilov found quite a short solution. He published his work online in russian about a month ago.

I´d like to share these ideas with englisch speaking Django community in order to help others simplify their code. It might come handy for such a "simple" at first glance issues.

Long story short, let's dive into the code:

Imagine you are building an E-commerce project. You have a ProductModelwhich have O2M relation to ImageModel.

You also need ModelAdmins for given models.

Now let's create a simple inline to put into our ProductModelAdmin.

So far we have two simple models and basic ModelAdmins with an InlineModel.

How should we squeeze that Inline above or in between the two fields of the ProductModelAdmin?

I suppose, you are familiar with the added field concept in ModelAdminForm. You can create a method in the ModelAdmin to display the response of the method in the form as a readonly field.
Keep in mind, that the rendering sequence of the ModelAdmin will create the InlineModels first, then render AdminForm and after that render the InlineForms.

We can use that to rearrange the order of Inlines and fields.

We use the render_change_form to get the objects request and response.
We use those objects in the image_inline method to take one inline_formset from the list of inline_admin_formsets that have not been processed yet, and render InlineFormset.

After the change_form rendering the remaining inline_admin_formsets will be rendered, in case if the ModelAdmin still has some.

Now we can use the method image_inline to determine the position of our InlineFormset.
With the code-snippet above the inline element will be placed above all other fields.

When we rearrange the fields this way the inline is rendered between the fields:

Of course Django admin adds a lable infront of the Inline with the name of the method, but that can be easily removed by some simple CSS in Media attribute of ProductModelAdmin.

This solution has one fatal error! Every Django ModelAdmin is singelton, that is why we can not use ModelAdmin.self as a container in render_change_form!

It is possible to change the ModelAdmins singleton´s behavior with a Mixin, staying inline with the concept of Djangos GCBV. We will take a closer look at it in my next article.

It simply means, that we can't use the instance of the ModelAdmin as a container to save our request and response.
The solution is to save those objects in the AdminForm instance.

The argument obj is not always given in render_change_form (i.e. add new object). That is why we have to get it from the ModelForm, which is wrapped into the AdminForm.

Now we can set our request and response as attributes of the ModelForm instance and use those in image_inline.

Summing up the above: you don't have to install another battery to your project to solve a simple problem. Sometimes you need to dig deep enough into the framework that you use, and find a simple, short and quick solution.

I´d like to thank Martin Achenrainer the intern of wPsoft for contributing to this article and translating it.

DEV Community: Maxim Danilov

Django Nested Inline. Save Data.

Form prefixes

Data validation

save method

Form encoding

Limitations

Next Article

Django nested inline redering

Introspection of existed Nested Inline packages

Basic Nested Inline rendering

Next Article

Autoregister Django ModelAdmins

Standard `ModelAdmin` registration

Django `ModelAdmins` integrated auto-register.

Benefits

1. Shorter Code

2. Easier development

3. Circular Imports

Variations

Register specific models only

Remove standard registered models

How to solve the singleton problem in Django ModelAdmin.

Table of Content:

The problems

1. Multiple users can not work normally with the same `ModelAdmin` at the same time.

2. Hacks

3. Speed

The solution

Conclusion

Django devs

The Singleton Problem talk at PyCon 2022

The Python and Django conferences you don't want to miss in 2022

In my opinion, expert talks at a Conference are not just the best way to present new ideas, but also the most efficient way to learn new things. It will be my pleasure to answer your questions and exchange opinions after the talks. Feel free to approach and contact me there and...

Django admin dynamic Inline positioning

Summing up the above: you don't have to install another battery to your project to solve a simple problem. Sometimes you need to dig deep enough into the framework that you use, and find a simple, short and quick solution.

DEV Community: Maxim Danilov

Django Nested Inline. Save Data.

Form prefixes

Data validation

save method

Form encoding

Limitations

Next Article

Django nested inline redering

Introspection of existed Nested Inline packages

Basic Nested Inline rendering

Next Article

Autoregister Django ModelAdmins

Standard ModelAdmin registration

Django ModelAdmins integrated auto-register.

Benefits

1. Shorter Code

2. Easier development

3. Circular Imports

Variations

Register specific models only

Remove standard registered models

How to solve the singleton problem in Django ModelAdmin.

Table of Content:

The problems

1. Multiple users can not work normally with the same ModelAdmin at the same time.

2. Hacks

3. Speed

The solution

Conclusion

Django devs

The Singleton Problem talk at PyCon 2022

The Python and Django conferences you don't want to miss in 2022

In my opinion, expert talks at a Conference are not just the best way to present new ideas, but also the most efficient way to learn new things. It will be my pleasure to answer your questions and exchange opinions after the talks. Feel free to approach and contact me there and...

Django admin dynamic Inline positioning

Summing up the above: you don't have to install another battery to your project to solve a simple problem. Sometimes you need to dig deep enough into the framework that you use, and find a simple, short and quick solution.

Standard `ModelAdmin` registration

Django `ModelAdmins` integrated auto-register.

1. Multiple users can not work normally with the same `ModelAdmin` at the same time.