admin
admin beDjango Comes with a backend management component that allows you to perform operations such as additions, deletions, changes, etc. in admin.
It is very convenient to let you manipulate the model table in a visual way.
Basic use
Data preparation
As follows, in theapp01 There is a table of such models in the
from import models
# Create your models here.
class User():
user_id = (primary_key=True, verbose_name="User ID")
user_name = (max_length=32, verbose_name="Username")
user_gender = (
choices=([0, "male"], [1, "female"]), verbose_name="Gender of the user")
user_introduction = (
max_length=1024, null=True, blank=True, verbose_name="User Profile")
def __str__(self):
return self.user_name
Create User
When the database migration command has been run, you need to create a loginableadmin Managed Super Accounts.
python createsuperuser
It will prompt you for a username, and a password, which cannot be less than eight digits.
Email is optional.
Register for admin
After the administrator user is created, theapp01 Register under the application.
from import admin from .models import * (User)
Next, open theadmin , after entering your account name and password, you can see this table.
Next you can add, delete, and check the table.
Deep Configuration
Models
When you create a model table, you can add a number of fields to the field that are related to theadmin Related Parameters.
| parameters | descriptive |
|---|---|
| verbose_name | Name of the field displayed in Admin |
| blank | Can the field be empty when adding or editing in Admin? |
| editable | Whether the field can be edited in Admin |
| help_text | Helpful information in Admin |
| choices | What the checkbox displays in Admin |
It's here.blank together withverbose_name as well aschoices All are more commonly used.
In addition to configuring on the fields of the model table, it is also possible to customize the meta information under that table. This has information about how the table is configured in theAdmin The information in is displayed as follows:
class User():
field = typology(prerequisite)
field = typology(prerequisite)
class Meta:
verbose_name = "Table name displayed in Admin"
admin configuration
If you want to configure a registered table in depth, you can do so in the in the middle to it.
There are two commonly used configurations, as shown below:
from import admin # Decorator registration @(User) class UserConfig(): configuration item.... # Use site class UserConfig(): configuration item.... (CustomAdmin, UserConfig) # 应用configuration item
Here are some common options for admin depth configuration.
from import admin
from .models import *
# Register your models here.
class UserConfig():
# Customized fields, role display
def edit(self):
return "Edit."
# The following is the use of custom admin
# Add data template page
# add_form_template = None
# Modify template pages for data
# change_form_template = None
# Modify template pages with multiple data
# change_list_template = None
# Delete confirmation message template page
# delete_confirmation_template = None
# Confirmation page for deletion of linked data
# delete_selected_confirmation_template = None
# Template pages for revision history
# object_history_template = None
# Popup box template page
# popup_response_template = None
# Do not support many-to-many fields, show fields in table.
list_display = ["user_id", "user_name","user_gender",edit]
# Click on the field to go to the change page
list_display_links = [edit]
# Filtering filters to support relationships
list_filter = ["user_gender"]
# Support for fields modified on the page, conflicting with list_display_links
list_editable = ["user_name"]
# Fuzzy search, can search by number, name.... or relationships
search_fields = ["user_id","user_name"]
# Used to do batch processing with action customization items
def patch_init(self,request,queryset):
"""
queryset:selected dictionary
"""
# Change all selected users to male...
(user_gender=False)
# Add description
patch_init.short_description = "Batch change of gender"
actions = [patch_init]
(User)
The following is the style after the configuration is completed. You can view it after configuring the corresponding configuration items by yourself.
Chinese display
If you want to be in theadmin If you want to display Chinese characters in the global Configure the language in the
# LANGUAGE_CODE = 'en-us' LANGUAGE_CODE = 'zh-Hans' # Chinese display
Implementation process
at startupdjango The first step when the project goessettings The various modules are imported in the
INSTALLED_APPS = [ '', '', '', '', '', '', '.App01Config', ]
ferret outadmin source code (computing)from import admin , which has such a function underneath it, the function's role is to take all theapp loweradmin Both do an import.
def autodiscover():
autodiscover_modules('admin', register_to=site)
We know that when a module is imported, it runs the code in that module, so the When performing registration, you are actually applying the singleton pattern for registration.
utilization() It's all actually using the methods under the singleton object and doesn't generate multiple objects over and over again.
class AdminSite(object):
def __init__(self):
self._registry = {}
def register(self, model, admin_class = None):
# Setup configuration classes
if not admin_class:
admin_class = ModelAdmin
self._registry[model] = admin_class(model, self)
site = AdminSite() # last line
admin The application of the singleton object in is also very simple; it applies the singleton object as a module, since we know that the module will only be executed once.
As shown below:
# Modules
class Test(object):
def __init__(self,name):
= name
t1 = Test("Testing.")
When other files are imported multiple times, they will only be imported once, and the t1 used at that time will always be a singleton object and will not be instantiated repeatedly:
import f1 f1.t1()
Above is the use of Django admin component details, more information about Django admin component please pay attention to my other related articles!