serie Django Análisis de configuración y estructura del proyecto Django.

Autor : Li Juncai (jcLee95) : https://blog.csdn.net/qq_28550263
Correo electrónico: [email protected]
Dirección del artículo : https://blog.csdn.net/qq_28550263/article/details/132893616

【介绍】：本文讲解Django的项目结构与配置。

Sección anterior: " Configuración del entorno de desarrollo de Django y el primer proyecto (proyecto) de Django " | Sección siguiente: " Creación y configuración de la aplicación (app) de Django "

Tabla de contenido

1. Información general
2. Estructura del proyecto Django
3. Archivo de configuración de Django settings.py
F. Adjunto: Un archivo de configuración inicial real

Insertar descripción de la imagen aquí

1. Información general

Este artículo presenta la estructura general del proyecto Django. Esta es solo la estructura básica del proyecto Django, incluida la función de cada archivo y directorio, y cómo especificarlos a través del archivo de configuración (settings.py) del proyecto Django; y luego presenta de manera integral un Django inicial Las funciones y métodos de configuración de cada elemento de configuración en el archivo settings.py del proyecto.

2. Estructura del proyecto Django

La estructura del proyecto Django se refiere a la organización de directorios y archivos contenida en un proyecto típico de Django. Esta estructura está diseñada para proporcionar una forma clara, mantenible y escalable de organizar el código y los recursos del proyecto.

2.1 Raíz del proyecto

El directorio de nivel superior del proyecto, normalmente el nombre del proyecto. En este directorio encontrará los archivos de configuración del proyecto, aplicaciones de nivel superior, archivos estáticos, plantillas, etc.

manage.py: El archivo de entrada de la herramienta de gestión de proyectos Django, utilizado para ejecutar varios comandos de gestión.
myproject/(Nombre del proyecto): el paquete Python del proyecto, que también es el directorio principal del proyecto.
requirements.txt: muestra una lista de todos los paquetes de Python necesarios para el proyecto, normalmente instalados mediante pip.

Por ejemplo, la siguiente es la estructura del directorio de archivos de un proyecto que ha pasado por la migración de la base de datos (migración) en la consola:

myproject
├── myproject
│   ├── __init__.py    # 用于将 myproject 目录标识为 Python 包
│   ├── asgi.py        # ASGI 应用程序入口点，用于支持异步 Web 服务器
│   ├── settings.py    # 项目的主要设置文件，包括数据库配置、应用程序设置等。
│   ├── urls.py        # URL 路由配置文件，定义了 URL 映射到视图函数的规则。
│   └── wsgi.py        # 用于生产环境部署的 WSGI 应用程序入口点。
├── db.sqlite3         # SQLite 数据库文件，项目中的默认数据库。
└── manage.py          # Django 项目管理工具，用于执行各种管理命令，如启动开发服务器、创建数据库迁移等。

Nota: Generalmente instalamos las dependencias requeridas por el proyecto Django actual en un entorno virtual. Una vez completado el desarrollo, exportamos los paquetes utilizados por este proyecto en el entorno virtual, no los paquetes utilizados por el sistema Python. Puede utilizar el siguiente comando para exportar el archivo pip instalado y escribir requirements.txtun texto llamado:
pip freeze > \path\to\requirements.txt       # 替换为你想保存requirements.txt文件的位置
Cuando necesitemos restaurar las dependencias en este texto en un nuevo entorno al mismo tiempo, podemos ejecutar el siguiente comando:
pip install -r requirements.txt
De esta manera no solo se pueden migrar proyectos de Django, sino también otros proyectos de Python.

2.2 Catálogo de aplicaciones (aplicaciones)

Un proyecto Django puede contener múltiples aplicaciones, cada aplicación es responsable de manejar una función o módulo específico en el proyecto. Cada aplicación tiene su propia estructura de directorios, que normalmente incluye lo siguiente:

models.py: Defina el modelo de datos de la aplicación, incluida la estructura y los campos de las tablas de la base de datos.
views.py: Defina la función de visualización de la aplicación, maneje solicitudes HTTP y genere respuestas HTTP.
urls.py: Defina las reglas de asignación de URL de la aplicación para asociar solicitudes de URL con funciones de visualización.
templates/: almacena el archivo de plantilla HTML de la aplicación y se utiliza para generar contenido de la página.
static/: Almacena los archivos estáticos de la aplicación, como CSS, JavaScript, imágenes, etc.
Otros módulos personalizados y archivos de recursos.

2.3 Archivo de configuración

El archivo de configuración de un proyecto Django generalmente se encuentra en un subdirectorio del mismo nombre en el directorio raíz del proyecto settings.pyy se usa para configurar varias configuraciones del proyecto, incluidas conexiones de bases de datos, rutas de archivos estáticos, configuraciones de internacionalización, etc.

2.4 Directorio de migración de bases de datos

Contiene archivos para la migración de bases de datos, utilizados para administrar cambios en el esquema de la base de datos. Cada vez que cambia su modelo de datos, Django genera automáticamente nuevos archivos de migración y puede usar los comandos makemigrationsy migratepara aplicar los cambios.

2.5 Directorio de archivos estáticos

El directorio de archivos estáticos de Django se utiliza para almacenar archivos estáticos utilizados en el proyecto, incluidas hojas de estilo CSS, scripts JavaScript, imágenes, fuentes, etc. Estos archivos estáticos normalmente no contienen contenido dinámico, sino que son recursos externos que se utilizan para representar la página web. En Django, puedes configurar dónde se almacenan los archivos estáticos y cómo se accede a ellos para que estos recursos se carguen correctamente tanto en entornos de desarrollo como de producción.

2.5.1 Configuración del directorio de archivos estáticos

En el archivo de configuración del proyecto Django settings.py, hay una STATIC_URLconfiguración llamada que se utiliza para definir la ruta URL del archivo estático. Esta es la ruta a la que se hace referencia a los archivos estáticos al generar páginas HTML.

STATIC_URL = '/static/'

En la configuración predeterminada, STATIC_URLestá establecido en /static/, lo que significa que todas las URL de archivos estáticos /static/comienzan con .

2.5.2 Archivos estáticos en la aplicación

Las aplicaciones Django normalmente contienen un staticdirectorio llamado que contiene los archivos estáticos de la aplicación. Estos archivos están organizados por aplicación, cada aplicación tiene su propio staticdirectorio que contiene recursos estáticos relacionados con la aplicación. Por ejemplo:

myapp/
   ├── static/
   │   └── myapp/
   │       ├── css/
   │       │   └── style.css
   │       ├── js/
   │       │   └── script.js
   │       └── img/
   │           └── logo.png

En el árbol de arriba, myappla aplicación tiene un directorio asociado static, que contiene archivos CSS, JavaScript y de imagen. Desde una perspectiva de back-end, algunos archivos js y css de terceros se colocan con mayor frecuencia en estos directorios, como archivos relacionados con bootstrap y jquery.

2.5.3 Cargar archivos estáticos

En las plantillas HTML, puede utilizar {% static %}la etiqueta de plantilla para cargar archivos estáticos. Esta etiqueta generará STATIC_URLla ruta URL correcta según la configuración.

<link rel="stylesheet" href="{% static 'myapp/css/style.css' %}">
<script src="{% static 'myapp/js/script.js' %}"></script>
<img src="{% static 'myapp/img/logo.png' %}" alt="Logo">

En el ejemplo anterior, {% static %}la etiqueta convierte una ruta relativa a un archivo estático en una URL completa.

2.5.4 Colección de archivos estáticos

En un entorno de producción, Django normalmente no entrega archivos estáticos de forma inmediata. En cambio, recopila estos archivos en una ubicación centralizada para mejorar el rendimiento. Puede utilizar el siguiente comando para recopilar archivos estáticos:

python manage.py collectstatic

Esto recopilará todos los archivos estáticos de la aplicación en un directorio específico, generalmente el directorio bajo el directorio raíz del proyecto static/.

2.5.5 Opciones de configuración para archivos estáticos

Django también proporciona otras opciones de configuración relacionadas con archivos estáticos, como:

STATIC_ROOT: especifique el directorio raíz utilizado para recopilar archivos estáticos. De forma predeterminada, es el directorio bajo la raíz del proyecto static/. En un entorno de producción, normalmente es necesario configurarlo en una ruta a la que pueda acceder el servidor web.
STATICFILES_DIRS: una lista que contiene directorios de archivos estáticos para buscar adicionalmente. Normalmente se utiliza para contener archivos estáticos a nivel de proyecto, en lugar de archivos a nivel de aplicación.

Estas opciones de configuración se pueden settings.pypersonalizar para satisfacer las necesidades específicas de su proyecto.

El directorio de archivos estáticos es una parte importante de un proyecto Django, ya que permite a los desarrolladores administrar y servir eficazmente recursos estáticos para garantizar que el sitio web se vea y funcione correctamente.

2.6 Directorio de plantillas (Plantillas)

El directorio de plantillas ( Templates) juega un papel clave en el proyecto Django. Se utiliza para almacenar archivos de plantillas HTML, que se utilizan para generar contenido web. La función de vista de Django seleccionará la plantilla apropiada para renderizar según la solicitud y devolverá la página HTML generada al usuario. Aquí hay una explicación detallada del directorio de plantillas, que incluye cómo configurar Django para buscar y usar plantillas:

2.6.1 Configuración del directorio de plantillas

En el archivo de configuración del proyecto Django settings.py, hay una TEMPLATESconfiguración llamada, que es una lista que contiene configuraciones de plantilla. Cada diccionario de esta lista representa una configuración del motor de plantilla. Normalmente, BACKENDse especifica el backend del motor de plantillas y DIRSel directorio donde se encuentran los archivos de plantilla.

TEMPLATES = [
    {
    
    
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],  # 在这里配置模板目录的路径
        'APP_DIRS': True,
        'OPTIONS': {
    
    
            'context_processors': [
                # ...
            ],
        },
    },
]

'DIRS': Esta es una lista que contiene rutas a directorios de plantillas. Aquí puede especificar directorios de plantillas personalizados en los que Django buscará archivos de plantilla. templates/Por ejemplo, si desea que los archivos de plantilla se almacenen en una carpeta en la raíz de su proyecto , puede configurarlo para que sea 'DIRS': [BASE_DIR / 'templates'].

2.6.2 Opción APP_DIRS

APP_DIRSes una opción en la configuración de la plantilla. Si se establece en True, Django buscará un subdirectorio nombrado en el directorio de cada aplicación instalada templatesy lo agregará a la ruta de búsqueda de la plantilla. Esto significa que cada aplicación puede tener su propio directorio de plantillas, lo que facilita la organización de las plantillas dentro de la aplicación.

2.6.3 Reglas de nomenclatura para archivos de plantilla

Los archivos de plantilla de Django suelen .htmltener una extensión de , pero se pueden utilizar otras extensiones. Las plantillas a menudo reciben nombres asociados con funciones o modelos de vista para que sean más fáciles de entender y administrar. Por ejemplo, si tiene una blogaplicación llamada , la plantilla de página de lista de artículos en esa aplicación podría llamarse article_list.html.

2.6.4 Herencia de plantilla

El sistema de plantillas de Django admite la herencia de plantillas, que es una forma de dividir las plantillas en fragmentos reutilizables. La etiqueta {% block %}le permite definir bloques en una plantilla base y luego anular estos bloques en plantillas secundarias. Esto facilita la creación de páginas con una apariencia y un diseño consistentes. Aquí hay un ejemplo:

Plantilla básica base.html:

<html>
<head>
  <title>{% block title %}My Site{% endblock %}</title>
</head>
<body>
  <div id="content">
    {% block content %}{% endblock %}
  </div>
</body>
</html>

Subplantilla article_list.html:

{% extends "base.html" %}
   
{% block title %}Article List{% endblock %}
   
{% block content %}
<h1>Article List</h1>
<!-- 页面内容 -->
{% endblock %}

En el ejemplo anterior, article_list.htmlla plantilla hereda base.htmlla plantilla y anula titlelos contentbloques y.

2.6.5 Etiquetas y filtros de plantilla

Django proporciona un amplio conjunto de etiquetas de plantilla y filtros para ejecutar lógica y procesar datos en plantillas. Las etiquetas están {% %}envueltas con y los filtros { { }}están envueltos con . Por ejemplo, puede utilizar {% for %}la etiqueta para recorrer una lista y { { value|filter }}la sintaxis para filtrar variables.

{% for article in articles %}
  <h2>{
   
   { article.title }}</h2>
  <p>{
   
   { article.content|linebreaks }}</p>
{% endfor %}

2.6.6 Secuencia de carga de plantillas

El sistema de plantillas de Django busca archivos de plantilla en un orden determinado, normalmente desde el más específico hasta el más general. Primero, busca plantillas en el directorio de la aplicación, luego un directorio personalizado (si está configurado) y finalmente el directorio de plantillas integrado de Django.

Estos son los conceptos y configuraciones básicos sobre el directorio de plantillas de Django. Las plantillas son una parte clave para generar contenido web dinámico en Django, lo que le permite organizar el código web de una manera más clara y modular, mejorando la eficiencia del desarrollo y la mantenibilidad.

2.7 Directorio de archivos de prueba (Pruebas)

Contiene los archivos de prueba del proyecto, utilizados para escribir y ejecutar pruebas unitarias y de integración.

2.8 Entorno de aislamiento virtual

Un entorno virtual Python se utiliza para aislar las dependencias de un proyecto y puede estar en venv/un directorio ubicado bajo el directorio raíz del proyecto. El entorno virtual contiene los paquetes de Python requeridos por el proyecto para garantizar que las dependencias del proyecto no entren en conflicto con el entorno global de Python. Sin embargo, esto no es obligatorio; si lo prefiere, simplemente tenga fácil acceso al entorno de aislamiento virtual.

3. Archivo de configuración de Django settings.py

El siguiente es un análisis de sección de cada parte del archivo de configuración de Django anterior settings.py:

3.1 Ruta básica y generación de archivos

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

En esta parte, BASE_DIRla variable se establece en el directorio superior del directorio donde se encuentra el archivo de configuración actual, que se utiliza para crear otras rutas en el proyecto.

3.2 Iniciar rápidamente la configuración de desarrollo

SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'
DEBUG = True
ALLOWED_HOSTS = []

Aquí se establecen algunas opciones de desarrollo rápido para el proyecto, incluidas claves, modo de depuración y hosts permitidos. Tenga en cuenta que estas configuraciones deben modificarse en un entorno de producción.

Al analizar SECRET_KEYy DEBUGestos ALLOWED_HOSTSelementos de configuración, podemos explicar en detalle su significado y función en el proyecto Django.

3.2.1 `SECRET_KEY`Configuración

SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'

SECRET_KEYEs un elemento de configuración muy importante en el proyecto Django y se utiliza para cifrar y proteger datos confidenciales, como sesiones de usuario y contraseñas. Esta clave es la semilla utilizada para cifrar y descifrar datos.

Función :
- Proteger sesiones de usuario: SECRET_KEYse utiliza para firmar y verificar sesiones de usuario para garantizar la seguridad del estado de inicio de sesión del usuario.
- Contraseñas cifradas: al almacenar y verificar las contraseñas de los usuarios, se utilizan claves para cifrar y descifrar las contraseñas para garantizar su confidencialidad.
Ejemplo :
normalmente, SECRET_KEYel valor de es una cadena generada aleatoriamente, por ejemplo:
```
SECRET_KEY = '2m_5#&^ihfw7z(b^^7+0^3wb*gj4%j4*#j%(9-ted-5q(^7p4z'
```
En un entorno de producción, la clave real no debe estar codificada en el archivo de configuración, sino cargada desde una variable de entorno para mayor seguridad.

3.2.2 `DEBUG`Configuración

DEBUG = True

DEBUGEl elemento de configuración se utiliza para controlar si el modo de depuración está habilitado. Durante el desarrollo, esto suele configurarse Truepara obtener información detallada sobre errores y herramientas de depuración. En un entorno de producción, esto debe configurarse Falsepara reducir los riesgos de seguridad.

Función :
- Modo de depuración: cuando DEBUGse establece en True, Django proporcionará páginas de error detalladas, seguimientos de pila e información de depuración para desarrollar y depurar aplicaciones.
- Seguridad: en un entorno de producción, DEBUGconfigurar Falsereducirá la exposición de mensajes de error, mejorando así la seguridad de su aplicación.
Ejemplo :
durante el desarrollo, puede DEBUGconfigurar Truepara ver información detallada de errores. En producción esto debería establecerse en False, por ejemplo:
```
DEBUG = False
```

3.2.3 `ALLOWED_HOSTS`Configuración

ALLOWED_HOSTS = []

ALLOWED_HOSTSLos elementos de configuración se utilizan para definir la lista de hosts a los que se les permite acceder a la aplicación. Esta es una configuración de seguridad que limita qué hosts pueden conectarse a la aplicación.

Función :
- Seguridad: a través de la configuración ALLOWED_HOSTS, puede evitar solicitudes de hosts maliciosos, mejorando así la seguridad de su aplicación.
- Configure varios nombres de dominio: se pueden agregar varios nombres de dominio o direcciones IP ALLOWED_HOSTSpara permitir que varios hosts accedan a la aplicación.
Ejemplo :
en un entorno de producción, se debe agregar el nombre de dominio o la dirección IP real ALLOWED_HOSTS, por ejemplo:
```
ALLOWED_HOSTS = ['example.com', 'www.example.com', '192.168.1.100']
```
Esto permitirá example.comy accederá a la aplicación, mientras denegará las solicitudes de otros hosts www.example.com.192.168.1.100

En resumen SECRET_KEY, DEBUGy ALLOWED_HOSTSson elementos de configuración clave en el proyecto Django y afectan directamente la seguridad y el comportamiento del proyecto. En un entorno de producción, es importante configurar estas opciones cuidadosamente para garantizar la estabilidad y seguridad de la aplicación.

3.3 Definición de aplicación

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

INSTALLED_APPSEnumera las aplicaciones instaladas en el proyecto. Estas aplicaciones incluyen algunas aplicaciones integradas proporcionadas por Django, como interfaces de administración, sistemas de autenticación, etc. Puede ver que al comienzo de la creación del proyecto, se instalaron algunas aplicaciones de marco predeterminadas.

La siguiente es una introducción a varias aplicaciones integradas predeterminadas.

3.3.1 django.contrib.admin

La aplicación proporciona una poderosa interfaz de administración de backend para administrar datos en la base de datos y la configuración de aplicaciones Django. Permite a los usuarios administradores agregar, modificar y eliminar fácilmente registros de bases de datos. Los administradores pueden iniciar sesión en la ruta /admin y usar la aplicación para administrar los datos de la base de datos de la aplicación.

(Por ejemplo, http://127.0.0.1:8000/admin)
Insertar descripción de la imagen aquí

3.3.2 django.contrib.auth

La aplicación proporciona un sistema de autenticación y autorización de usuarios, que incluye registro de usuarios, inicio de sesión, restablecimiento de contraseña, grupos de usuarios y otras funciones. Permite la gestión de usuarios, grupos de usuarios y permisos. Los usuarios pueden registrarse para obtener cuentas, iniciar sesión en la aplicación y acceder a vistas que requieren autenticación.

3.3.3 django.contrib.tipos de contenido

La aplicación proporciona un marco de tipo de contenido que permite crear relaciones genéricas y encontrar asociaciones entre modelos. Se puede utilizar para crear claves foráneas universales, relaciones inversas y relaciones polimórficas. Permite asociaciones entre modelos, por ejemplo un modelo de comentario se puede asociar a un modelo de artículo o imagen.

3.3.4 sesiones de django.contrib

La aplicación proporciona funcionalidad de gestión de sesiones para almacenar y recuperar datos de sesiones de usuarios en aplicaciones web. Se puede utilizar para rastrear y administrar el estado de inicio de sesión del usuario. Puede utilizar sesiones para almacenar datos como el contenido del carrito de compras, las preferencias del usuario y más.

3.3.5 django.contrib.mensajes

La aplicación proporciona un marco de notificación de mensajes para mostrar mensajes únicos al usuario, como mensajes de éxito, error o informativos. Ayude a los usuarios a obtener comentarios sobre los resultados de sus acciones. Puede mostrar un mensaje de éxito o error al usuario después de enviar el formulario.

3.3.6 django.contrib.archivos estáticos

La aplicación maneja la recopilación y entrega de archivos estáticos como CSS, JavaScript y archivos de imagen. Administre los recursos estáticos en su aplicación para poder usarlos en plantillas.

3.4 Configuración del middleware

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

MIDDLEWARELa lista contiene middleware que se ejecuta durante el procesamiento de solicitudes y respuestas. El middleware se utiliza para realizar diferentes tareas como seguridad, gestión de sesiones, autenticación, etc.

3.5 Configuración de URL (especificar y enrutar archivos)

ROOT_URLCONF = 'myproject.urls'

ROOT_URLCONFEstablece el módulo utilizado para definir asignaciones de URL en el proyecto.

3.6 Configuración de plantilla

TEMPLATES = [
    {
    
    
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
    
    
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

TEMPLATESLa lista configura opciones para el motor de plantillas en el proyecto, incluidos directorios de plantillas y procesadores de contexto.

3.7 Configuración de la aplicación WSGI

WSGI_APPLICATION = 'myproject.wsgi.application'

WSGI_APPLICATIONConfigure la aplicación WSGI utilizada para definir el proyecto.

3.8 Configuración de la base de datos

DATABASES = {
    
    
    'default': {
    
    
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

DATABASESEl diccionario contiene opciones de configuración para la base de datos del proyecto, incluido el motor de la base de datos y las rutas de los archivos de la base de datos.

en:

'BACKEND': Se utiliza para especificar el motor de plantilla que se utilizará. Por ejemplo, normalmente esto debería establecerse en 'django.template.backends.django.DjangoTemplates'porque Django viene con un motor de plantilla backend.
'DIRS': Contiene una lista de rutas de directorio de plantillas adicionales. Estas rutas se utilizan para buscar archivos de plantilla personalizados. templatesPor ejemplo, si tiene una plantilla personalizada almacenada en una carpeta en la raíz de su proyecto , puede agregar la ruta a esta lista:'DIRS': [BASE_DIR / 'templates'],
'APP_DIRS': Especifica si se debe buscar el directorio de plantillas en la aplicación. Por ejemplo, configúrelo en True, para habilitar la búsqueda en el directorio de plantillas de la aplicación.
'OPTIONS': Diccionario que contiene opciones adicionales del motor de plantillas. Por ejemplo, en 'OPTIONS', puede configurar algunas otras opciones, de la siguiente manera:
```
'OPTIONS': {
      
      
    'context_processors': [  # 上下文处理器
        'django.template.context_processors.debug',  # 调试信息
        'django.template.context_processors.request',  # 请求对象
        'django.contrib.auth.context_processors.auth',  # 认证用户
        'django.contrib.messages.context_processors.messages',  # 消息通知
    ],
    'builtins': [
        'myapp.template_tags.my_template_tag',  # 自定义模板标签
    ],
},
```
- 'context_processors'La lista contiene los nombres de los procesadores de contexto que pueden proporcionar datos contextuales adicionales a la plantilla. Por ejemplo, 'django.contrib.auth.context_processors.auth'la información del usuario autenticado se proporcionará a la plantilla.
- 'builtins'Contiene etiquetas y filtros integrados para usar en plantillas. Si tiene una etiqueta de plantilla personalizada, puede agregarla a esta lista.

Estos elementos de configuración permiten la personalización del comportamiento del motor de plantillas en su proyecto, incluidos directorios de plantillas, procesadores de contexto y etiquetas integradas. Según las necesidades del proyecto, el motor de plantillas se puede configurar de forma flexible para satisfacer las necesidades.

3.9 Configuración de verificación de contraseña

AUTH_PASSWORD_VALIDATORS = [
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

AUTH_PASSWORD_VALIDATORSLa lista define políticas de validación de contraseñas para garantizar la seguridad de las contraseñas de los usuarios. En la configuración predeterminada anterior:

'django.contrib.auth.password_validation.UserAttributeSimilarityValidator':
Este validador se utiliza para comprobar si la contraseña es demasiado similar a los atributos del usuario. Compara la contraseña con los atributos del usuario (como el nombre de usuario) para determinar si hay similitud y determina si la contraseña es segura en función de los requisitos de similitud establecidos.
'django.contrib.auth.password_validation.MinimumLengthValidator':
Este validador verifica que se cumpla la longitud mínima de la contraseña. El requisito de longitud mínima de la contraseña se puede establecer en la configuración de Django.
'django.contrib.auth.password_validation.CommonPasswordValidator':
Este validador se utiliza para comprobar si la contraseña contiene contraseñas débiles comunes, como "contraseña" o "123456". Comprueba la seguridad de las contraseñas con una lista de contraseñas comunes.
'django.contrib.auth.password_validation.NumericPasswordValidator':
Este validador se utiliza para comprobar si la contraseña contiene números. Requiere que la contraseña contenga al menos un carácter numérico.

Al agregar estos validadores a AUTH_PASSWORD_VALIDATORSla lista, Django garantiza la seguridad de las contraseñas para evitar que los usuarios utilicen contraseñas que sean demasiado simples o fáciles de adivinar. Esto ayuda a mejorar la seguridad del sistema y evita que las contraseñas sean atacadas o descifradas maliciosamente. Estos validadores se pueden personalizar o se pueden agregar validadores personalizados adicionales según los requisitos de seguridad del proyecto.

3.10 Configuración de internacionalización y zona horaria

LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_TZ = True

Estos ajustes se utilizan para configurar la internacionalización y la zona horaria del proyecto.

El siguiente es un análisis de la configuración de internacionalización y zona horaria en Django, incluidos los valores que se pueden tomar y el significado de cada valor:

3.10.1`LANGUAGE_CODE`

es una cadena, por ejemplo 'en-us', 'es-es'etc.
Esta configuración especifica el idioma y la configuración regional predeterminados para el proyecto. Determina el idioma utilizado en el proyecto y cómo se formatean las fechas, horas y números.

Por ejemplo, 'en-us'usar significa inglés americano, usar 'zh-hans'significa chino simplificado, usar 'zh-hant'significa chino tradicional; usar 'fr'significa francés; usar 'es-es'significa español; usar significa 'ru'ruso; usar significa persa; usar significa japonés 'fa'; usar significa coreano 'ja'; 'ko'usar 'la'significa latín, etc.

3.10.2`TIME_ZONE`

es una cadena, por ejemplo 'UTC', 'America/New_York'etc.
Esta configuración especifica la zona horaria predeterminada del proyecto. Afecta a todas las operaciones relacionadas con la fecha y la hora, asegurando que se calculen y muestren de acuerdo con la zona horaria especificada. Por ejemplo, 'UTC'para representar la hora universal coordinada, 'America/New_York'representa la hora del este.

3.10.3`USE_I18N`

es un valor booleano ( Trueo False).
Esta configuración indica si la internacionalización está habilitada. Si se establece en True, Django intentará LANGUAGE_CODElocalizar el contenido del proyecto de acuerdo con la configuración, incluido el formato de fecha, hora y número. Por ejemplo, Truesignifica que la internacionalización está habilitada y Falsesignifica que la internacionalización está deshabilitada.

3.10.4`USE_TZ`

es un valor booleano ( Trueo False).
Esta configuración indica si la compatibilidad con la zona horaria está habilitada. Si se establece en True, Django usará TIME_ZONEla configuración para manejar fechas y horas, asegurando que se muestren y calculen correctamente en la zona horaria especificada. Por ejemplo, Trueindica que la compatibilidad con zona horaria está habilitada e Falseindica que la compatibilidad con zona horaria está deshabilitada.

Estas configuraciones le permiten personalizar la internacionalización y la zona horaria de su proyecto para garantizar que su aplicación funcione correctamente en diferentes regiones y configuraciones locales. Dependiendo de las necesidades de su proyecto, puede configurar estos ajustes de acuerdo con las instrucciones anteriores.

3.11 Configuración de archivos estáticos

STATIC_URL = 'static/'

STATIC_URLRuta URL utilizada para definir archivos estáticos. En Django, los archivos estáticos normalmente incluyen CSS, JavaScript, imágenes y otros recursos de front-end que se utilizan para diseñar y funciones interactivas del sitio web. Define la ruta URL raíz de los archivos estáticos en el sitio web.

Por ejemplo, si STATIC_URLestá configurado en 'static/', los archivos estáticos URLcomenzarán http://example.com/static/con .

Normalmente, la configuración de STATIC_URL termina con una barra para garantizar que la ruta URL del archivo estático sea correcta. Esto se debe a que en Django, las rutas URL para archivos estáticos son relativas a la URL raíz.

Los archivos estáticos generalmente se almacenan en el staticdirectorio del proyecto y STATIC_URLse especifica cómo acceder a estos archivos estáticos.

Por ejemplo, si hay un style.cssarchivo CSS con nombre ubicado static/css/en el directorio, puede acceder a él con STATIC_URL+ .'css/style.css'

La ventaja de usar STATIC_URL es que cuando el proyecto necesita implementarse en diferentes entornos (desarrollo, pruebas, producción, etc.), solo necesita cambiar la configuración de STATIC_URL sin tener que modificar la ruta del archivo estático en la plantilla. Esto mejora la mantenibilidad y portabilidad del proyecto.

3.12 Configuración predeterminada del tipo de campo de clave principal

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

DEFAULT_AUTO_FIELDSe utiliza para definir el tipo de campo de clave principal predeterminado para el modelo. Esta configuración se introdujo en Django 3.2 y versiones posteriores y se utiliza para especificar el tipo de campo de clave principal predeterminado del modelo.

DEFAULT_AUTO_FIELDSe puede configurar en una variedad de valores diferentes, y cada valor corresponde a un tipo de campo de clave principal diferente para satisfacer las diferentes necesidades del proyecto.

'django.db.models.AutoField':
Este es el tipo de campo de clave principal predeterminado de Django. Genere automáticamente valores de clave principal de tipo entero de 32 bits. Adecuado para la mayoría de aplicaciones de tamaño pequeño a mediano.
'django.db.models.BigAutoField':
Genera automáticamente valores de clave primaria de tipo entero de 64 bits. Adecuado para procesar grandes conjuntos de datos para evitar el desbordamiento del valor de la clave principal.
'django.db.models.UUIDField':
Utilice UUID (Identificador único universal) como clave principal. Genere valores de clave primaria únicos a nivel mundial, adecuados para la combinación de datos entre múltiples bases de datos o sistemas distribuidos.
Tipos de campos de clave principal personalizados:
también puede definir sus propios tipos de campos de clave principal personalizados y DEFAULT_AUTO_FIELDhacer referencia a ellos en . Esto requiere que cree una models.Fieldclase de campo personalizada que herede de . Por ejemplo:
```
# 自定义主键字段类型
from django.db import models

class MyCustomPrimaryKey(models.Field):
    def db_type(self, connection):
        return 'my_custom_type'

# 在 settings.py 中使用自定义主键字段类型
DEFAULT_AUTO_FIELD = 'myapp.models.MyCustomPrimaryKey' # myapp 表示 Django 项目中的一个应用（app）的名称。
```
Aquí, myapp es un nombre de aplicación de muestra ficticio; debe reemplazarlo con el nombre de la aplicación en su proyecto real. De hecho, la configuración DEFAULT_AUTO_FIELD requiere una referencia a la aplicación y al modelo que contiene el campo de clave principal personalizado. Esto se debe a que el campo de clave principal personalizado debe definirse en un modelo de una aplicación en el proyecto. Entonces, myapp en myapp.models.MyCustomPrimaryKey es el nombre de la aplicación, modelos es el módulo de Python en la aplicación que contiene el campo de clave principal personalizado y MyCustomPrimaryKey es el nombre del campo de clave principal personalizado. Es decir, si realmente tiene una aplicación llamada myapp en su proyecto y el campo MyCustomPrimaryKey está definido en el archivo models.py de la aplicación, puede usar la configuración anterior. De lo contrario, reemplace myapp con el nombre real de la aplicación y asegúrese de que el campo de clave principal personalizado esté en el modelo de la aplicación.

La configuración DEFAULT_AUTO_FIELDle permite seleccionar un tipo de campo de clave principal predeterminado que se adapte a las necesidades de su proyecto para cumplir con los requisitos de rendimiento y administración de datos. Los diferentes tipos de campos de clave principal son adecuados para diferentes escenarios y se pueden seleccionar según las características del proyecto.

F. Adjunto: Un archivo de configuración inicial real

"""
Django settings for myproject project.

Generated by 'django-admin startproject' using Django 4.2.5.

For more information on this file, see
https://docs.djangoproject.com/en/4.2/topics/settings/

For the full list of settings and their values, see
https://docs.djangoproject.com/en/4.2/ref/settings/
"""

from pathlib import Path

# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent


# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/4.2/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []


# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

ROOT_URLCONF = 'myproject.urls'

TEMPLATES = [
    {
    
    
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
    
    
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

WSGI_APPLICATION = 'myproject.wsgi.application'


# Database
# https://docs.djangoproject.com/en/4.2/ref/settings/#databases

DATABASES = {
    
    
    'default': {
    
    
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}


# Password validation
# https://docs.djangoproject.com/en/4.2/ref/settings/#auth-password-validators

AUTH_PASSWORD_VALIDATORS = [
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]


# Internationalization
# https://docs.djangoproject.com/en/4.2/topics/i18n/

LANGUAGE_CODE = 'en-us'

TIME_ZONE = 'UTC'

USE_I18N = True

USE_TZ = True


# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/4.2/howto/static-files/

STATIC_URL = 'static/'

# Default primary key field type
# https://docs.djangoproject.com/en/4.2/ref/settings/#default-auto-field

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

Serie Django: estructura del proyecto Django y análisis de configuración