The Python framework's Django Learning notes (13)

Django Site Management (cont. 1)

The last time I introduced some of the basics of Django's site management, let's take a closer look at Django's site management.

How the Admin works:

Behind the scenes, how does the management tool work? It's actually very simple.

When the service starts, Django Boots urlconf from url.py, and then executes the "admin.autodiscover ()" statement. This function iterates through the installed_apps configuration and looks for the relevant admin.py file. If admin.pyis found under the specified app directory, it executes the code in it.

In the admin.py file under the Books application directory, each call to Admin.site.register () registers the module with the management tool. The Administration tool displays an edit/modify interface only for those modules that are explicitly registered.

The application Django.contrib.auth contains its own admin.py, so users and groups can be displayed automatically in Administrative tools. Other Django.contrib applications, such as django.contrib.redirects, are added to the administrative tools themselves, as are other third-party Django applications that are under the Web.

In summary, the management tool is actually a Django application that contains its own modules, templates, views, and Urlpatterns. You have to add it to the urlconf, just as you would add your own view. You can check its templates, views, and Urlpatterns under the Django/contrib/admin directory in the Django codebase, but don't try to modify any of the code directly, Because there are a lot of places where you can customize how the management tools work. (If you really want to browse the code for the Django Management tool, keep in mind that it does a bit of work on reading metadata about modules, so it's best to spend some time reading and understanding those code.) )

Set field optional

After fiddling with it for a while, you might find that the management tool has a limit: Editing a form requires you to fill in every field, but in some cases you want some fields to be optional. For example, we want the email field in the Author module to be optional, which allows you to not fill it. In the real world, you may not have registered an email address for each author.

In order to specify an optional email field, you simply edit the book module (recall the previous section, it's in the mysite/books/models.py file), in the email Add blank=trueto the field. The code is as follows:

1 class Author (models. Model):2     first_name = models. Charfield (max_length=30)3     last_name = models. Charfield (max_length=40)4     email = models. Emailfield (**blank=true**)   #* * To modify content inside

The code tells Django that the author's e-mail address allows for a null value to be entered. All fields are Blank=falseby default, which makes them not allowed to enter null values.

After you add blank=true , refresh the page Add author edit form (http://127.0.0.1:8000/admin/books/author/add/ ), You will find that the email label is no longer bold. This means that it is not a required field. Now you can add an author without having to enter an email address, even if you submit a null value for this field, you will never get that dazzling red message "this field is required".

However, there are exceptions to other data types: date, time, and numeric fields do not accept empty strings. If you try to insert an empty string into a date or integer field, you may get an error returned by the database, depending on the type of the database. (PostgreSQL is strictly forbidden, will throw an exception; MySQL may or may not be accepted, depending on the version you are using and your luck.) In this case,null is the only method that specifies a null value. In the Django module, you can specify that a field is allowed to be nullby adding null=true .

So this is a little bit more complicated: if you want to allow a date type ( , timefield , datetimefield ) or digital type (< Span class= "Pre" >integerfield , decimalfield , floatfield ) field is empty, you need to use null=true  * and *  blank=true .

book module modified to allow   is empty. The modified code is as follows:

1 class Book (models. Model):2     title = models. Charfield (max_length=100)3     authors = models. Manytomanyfield (Author)4     publisher = models. ForeignKey (Publisher)5    #* * Content    modified within 6     Publication_date = models. Datefield (**blank=true, null=true**)

custom field labels

In the edit page, each field's label is generated from the field name of the module. The rule is simple: replace the underscore with a space, and capitalize the first letter. For example : The publication_date tag in the book module is publication date.

However, field names are not always appropriate. In some cases, you may want to customize a label. You only need to specify verbose_namein the module.

For example, how to change the author.email label to e-mail with a horizontal line in the middle.

1 class Author (models. Model):2     first_name = models. Charfield (max_length=30)3     last_name = models. Charfield (max_length=40)4     email = models. Emailfield (blank=true, **verbose_name='e-mail'* *)
# * * Number is modified in the content

Note that you do not have to capitalize the first letter of verbose_name unless it is a sequential capitalization (for example: " Usa state " ). Django will automatically capitalize the initial letter appropriately and use verbose_name in other places that do not need to be capitalized. Finally, note that to make the syntax concise, you can pass it as a fixed-position parameter. This example has the same effect as the one above.

1 class Author (models. Model):2     first_name = models. Charfield (max_length=30)3     last_name = models. Charfield (max_length=40)4     email = models. Emailfield (* *"e-mail", * *  blank=true)#* * Number to modify the content

This does not apply to the Manytomanyfield and foreignkey fields, however, because their first argument must be a module class. In that case, you must explicitly use the verbose_name parameter name.

The Python framework's Django Learning notes (13)