Admin component Explanation

Admin component Explanation

Start the process based on the admin component to review the Django Project initiation to the request.

1 registering the admin component in the app
2django Project Launch
3 run to the custom admin when executing its following in the apps file class below the Ready function executes the admin file under each app when the project starts
4 When the user sends the request comes in first through WSGI processing
5 re-run each component in the middleware to process the request
6 find the corresponding view function in the URL and execute to return a response object
7 The returned object is then processed by the middleware (at which point the order is executed from the back)

Process

Knowledge points

1, Django admin using a Python unique singleton mode to invoke the execution of each py file in Python will generate a PYc file, when the next call, will not be executed once the Py file, but to get the data in the space of the previous raw PYc file.

2, the override method specifies that when the app launches, execute the stark file under each app directory

def ready:    autodiscover_modules (' Stark ')

　　

3 by viewing the registration method in the source admin through the site call, site is a file class generated by the singleton object, the new file defines a method to generate a site object, define the Register method

Class Starksite (object): Def __init__ (self, name= ' admin "): Self._registry = {} #记录注册的model类 def register (self, model, Admin_class=none, **options): if not admin_class:admin_class = Modelstark # config class Self._registry[model] = Admin_c Lass (model)

　　

4model registration into this should generate the corresponding URL, each table should have its own unique url,url corresponding to the table data additions and deletions, then design URL is particularly important, at this time we use the method of URL distribution, the first level of the route is named by the table name, level two route another class, to call ( Because site is a singleton, if written in a class, then each URL will need to generate 4 URLs, code duplication, should be in the user access to a table when the corresponding additions and deletions changed Anza by)

#一级路由代码

def get_urls (self):     temp = []      for Model_class, config_obj in Self._registry.items ():        print ("===>", Model_class, config_obj)         model_name = model_class._meta.model_name        App_label = Model_class._meta.app_label        print ("===>", App_label, Model_name)         temp.append (URL (r ' ^%s/%s/'% (App_label, model_name), Config_ Obj.urls))                

　　

5, Config_obj is the configuration class object, the level two route puts in the configuration class, when the user registers, if has own configuration class to use own, did not use the default

def get_urls (self):      temp=[        url ("^$", self.list_view,name= "%s_%s_list"% (self.app_model_name)),        url ("^ add/$ ", self.add_view,name="%s_%s_add "% (self.app_model_name)),        url (" ^ (\d+)/change/$ ", self.change_view,name= "%s_%s_change"%            (self.app_model_name)),        url ("^ (\d+)/delete/$", self.delete_view,name= "%s_%s_delete"% ( Self.app_model_name)),]         temp.extend (Self.extra_urls ())         return Temp@property                               # The role of this adorner is to make the method to call Def URLs (self) Like a property:   return Self.get_urls (), None,none

6 define additions and deletions under decoration Category 4 View methods

Flow chart

>

As for adding or deleting the method in the view, the basic logic of customizing the admin component is as described.