Django Management Interface

As we have mentioned many times before, the Django management interface is one of the killer features of the framework. most Django developers know that it is both time-saving and easy-to-use. As this management interface is very popular, it is common for Django developers to customize and expand it. As we have mentioned many times before, the Django management interface is one of the killer features of the framework. most Django developers know that it is both time-saving and easy-to-use. This management interface is very popular
It is common for Django developers to customize and expand it.

The last few sections of Django website management introduce some simple methods for customizing some management interfaces. Before entering this chapter, please first review that part of the information, which covers how to customize the change list and
Edit forms.

The Django management site also discusses when and how to use the management interface. since those materials are a good starting point for the rest of this chapter, we will repeat it here:

Obviously, this management interface is extremely useful for data editing (imagine ). If it is used to complete data entry, this management interface is truly unmatched. We suppose that most of the readers of this book have a pile of data input tasks.

The Django management interface pays special attention to users who have no technical background to use data input. this is also the purpose of this function. A typical online municipal water supply quality report system was developed at Django's first newspaper. the requirements are as follows:

§ A reporter in charge of the subject matter met a developer to submit existing data.

§ Developers design a model for the data and develop a management interface for the reporter.

§ When reporters input data into Django, programmers can focus on developing public access interfaces (the most interesting part !).

In other words, the primary purpose of the Django management interface is to facilitate the simultaneous work of content editors and programmers.

Of course, apart from the obvious data entry tasks, we found that the management interface is very useful in other situations.

§ Check the data model: After defining a new data model, the first thing we need to do is run it on the management interface and input some hypothetical data. After data modeling error is found, you can quickly find the problem on the graphical model interface.

Manage the data obtained: few real data inputs are associated with sites like http://chicagocrime.org, because most of the data comes from the automatically generated source. However, when an error occurs in the obtained data, you can easily locate and modify the error data, which will help solve the problem.

The Django management interface can handle most common situations without or just being customized. However, it is precisely because of the strong design compromise that the Django management interface can well handle this common situation, which means it cannot process other editing models as well.

Later, we will discuss what is not the Django management interface design for disposal, but first let's take a moment to discuss its design philosophy.

Management path

In the core part, the Django management interface is designed for only one action:

Trusted users edit structured content.

Yes, this is very simple, but it is built on a bunch of assumptions. All the design concepts of the Django management interface follow these assumptions directly, so let's have a deep understanding of the meanings of the terms mentioned in these subsequent sections.

Trusted users

The management interface is designed for use by developers like you. This is not just a person who passes authentication. it is said that Django assumes that content editors can only do the right thing.

Conversely, this means that if you trust users, they can edit the content without permission, and no one needs to permit their editing behavior. Another implication is that, despite the powerful functions of the authentication system, it does not support object-level basic access restrictions until the writing of this book. If you allow someone to edit their own news reports, you must be sure that the user will not edit others' reports without permission.

Edit

The primary purpose of the Django management interface is to allow users to edit data. At first glance, this is obvious, but when you think about it carefully, it becomes a bit unpredictable and extraordinary.

For example, although the management interface is very easy to check data (as discussed earlier), it is not its original design intention. For example, we mentioned in Django sessions, users, and registration that it lacks view permission. Django assumes that if someone can view the content on the management interface, they can also edit the content.

Pay attention to the lack of remote workflow calling. If a specific task is composed of a series of steps, there is no mechanism to ensure that these steps can be completed in a specific order. The Django management interface focuses on editing, but does not care about modifying the surrounding activities. This avoidance of workflows also comes from the trust principle: the management interface design concept is that workflows are human tasks and do not need to be implemented in code.

Finally, you must note that aggregation is missing in the management interface. That is to say, the display of sum, average, and other things is not supported. Again, the management interface is only used for editing-it is expected that you will complete all other work by defining the view.

Structured Content

In combination with other parts of Django, you are expected to use structured data on the management interface. Therefore, it only supports editing data stored in the Django model. for other data, such as data in the file system, you must customize the view to edit it.

Stop it.

It is certain that the Django management interface is not intended to be a universal tool for everyone. Instead, we chose to focus on one thing and make it perfect.

To expand the Django management interface, you must adhere to the same design philosophy. (Note: scalability is not our goal ). Because you can do anything by customizing the Django view, and also because they can be easily integrated into the management interface in a visual manner (which will be described in the next chapter ), the built-in opportunities for custom management interfaces are limited.

Remember that even though the management interface is complex, it is always an application. With sufficient time, any Django developer can do everything through the admin interface. Therefore, we need to hope that a different admin interface will appear in the future. This new interface has a series of different assumptions and works in different ways.

At the time of writing this article, Django developers are developing a new management interface. this version will provide more customization flexibility. When you read this article, these new features may have entered the real Django release. You can
Some people in the Django community know whether newforms-admin trunk code has been integrated.

Custom management templates

Django provides some tools for customizing built-in admin Management Templates. we will briefly introduce them. For other tasks (such as workflow control or more fine-grained permission management), you need to read the section "create custom admin" in this chapter.

Now let's take a look at how to quickly customize the appearance of the admin management interface. The Django management site has talked about some of the most common tasks: to modify the trademark (for those who hate the blue-colored tip hair bosses), or to provide a custom form.

Further goals often include changing some special items in the template. Each admin view, including the modification list, form editing, deletion confirmation page, and history view, has a template associated with it that can be overwritten in multiple ways.

First, you can overwrite the template globally. The admin view uses the standard template loading mechanism to find the template. So if you create a new template in the template directory, Django will automatically load it. Global templates are listed in Table 17-1.

Table 17-1. Global Management Template

View Base Template name

Change list admin/change_list.html

Add/edit form admin/change_form.html

Delete confirmation admin/delete_confirmation.html

Object history admin/object_history.html

Most of the time, you may just want to modify a single object or application, rather than modifying global settings. Therefore, every admin view always searches for templates related to models or applications. The order of these views to search for templates is as follows:

§ admin//
 
  /
  
   .html§ admin//
   
    .html§ admin/
    
     .html
    
   
  
 

For example, in the books application, the add/edit form view of the Book module looks for the template in the following order:

§ admin/books/book/change_form.html§ admin/books/change_form.html§ admin/change_form.html

Custom model template

Most of the time, you want to use the first template to create a template for a specific model. Generally, the best way is to expand the base template and add information to the block defined in the base template.

For example, we want to add some help text at the top of the book page. It may be something like the form shown in 7-1.

Figure 17-1. a custom management Editing form.

This is easy to do: just create an admin/bookstore/book/change_form.html template and enter the following code:

{% extends "admin/change_form.html" %}{% block form_top %}
Insert meaningful help message here...
{% endblock %}

All these templates define some blocks that can be overwritten. For most applications, code is the best document, therefore, we encourage you to read the admin template in detail to obtain the latest information (they are available in django/contrib/admin/templates /).

Custom JavaScript

Common uses of these custom model templates include adding custom javascript code to the admin page to implement some special view object or client behavior.

Fortunately, this can be simpler. Every admin template defines {% block extrahead % }.Add new content to the element. For example, if you want to add jQuery (http://jquery.com/) to your admin history, you can do this:

{% Extends "admin/object_history.html" % }{% block extrahead %}