La importancia de cómo escribir buen código con Django
Nota sobre el código de Django
1. Hay un conflicto entre extender e incluir en la etiqueta de la plantilla. Con extender, la inclusión no puede tener efecto. Diseño del mecanismo independiente de renderizado subyacente.
2. #coding: utf-8 Esta oración solo puede tener efecto si se coloca en la primera línea del archivo de código. Puede no ser válida si se coloca después de la cadena de comentarios.
3. Debido al desarrollo del front-end, la restificación de las solicitudes de publicación, la simplificación de la capa de instalaciones técnicas nativas de Django y el avance de la encapsulación de transacciones, el resultado es que la capa empresarial puede estar completamente colocado en las vistas. La ventaja de Restfulization es que las llamadas a módulos entre empresas se pueden colocar en el front-end, lo que garantiza la tangencia entre los módulos back-end.
4. Es mejor no colocar etiquetas XSRF en páginas generadas por el usuario. formulario POST con contenido de texto enriquecido, el primero puede robar la información del token del segundo.
5. Debe haber espacios en ambos lados de los símbolos de operación lógica comparativa como == en la plantilla; de lo contrario, afectará el análisis de la plantilla.
6. lógica interna de form.is_valid La excepción lanzada no se pasará hacia afuera, solo se convertirá en form.is_valid() y devolverá falso.
7. La forma más sencilla es ¿Qué nivel de parámetros debe pasar la capa empresarial? Personalmente, creo que es más apropiado pasar el formulario verificado.
8. Dos técnicas de simplificación para múltiples niveles si no: 1. Use excepto para manejar directamente; 2. Devuelva directamente la mitad del camino, aunque esto no cumple con el principio de diseño de funciones de programación de procedimientos. , el código es relativamente mucho más simple.
9. No puede imprimir Unicode chino en el entorno de producción de Ubuntu; de lo contrario, se producirá un error.
10. Debido al mecanismo 500 y al mecanismo de transacción de Django, la capa Ver de Django no lo hace. manejar el código de excepción La dependencia es relativamente débil.
11. Definición del formulario modelo: los campos que no aparecen en la página de inicio deben excluirse o ser nulos, pero Nulo afectará el valor predeterminado, por lo que la mejor manera es excluirlo; de lo contrario, incluso si está en blanco. También provocará errores al almacenar el formulario. Debido a que el campo no aparece en el formulario, el valor predeterminado se sobrescribirá a Nulo. Un método de definición más conveniente que excluir es definir metainformación de los campos, de modo que al agregar campos no utilizados al modelo, no sea necesario volver a actualizar la definición del formulario.
12 La visualización formateada de la hora. Los datos de zona en el inventario de datos deben colocarse en la plantilla. Cuando se opera con filtros como fecha, si usa striftime de fecha y hora para formatearlo directamente, los datos de zona horaria se perderán y la hora se convertirá en el valor de hora media de Greenwich. Si desea manejar strrifttime en el código, puede usar django.utils primero. Use el método .timezone.localtime para procesarlo, de modo que el tiempo que salga sea normal.
13. : Como todos sabemos, si se inicia el servidor de ejecución y se cambia el código, el servicio se reiniciará, pero si se cambia el código de etiqueta personalizado, el servicio no se reiniciará.
14. No hay información de texto en los errores de verificación de formularios en versiones anteriores. Leí la documentación hace algún tiempo y descubrí que la nueva versión tiene errores mejorados, como as_json() y as_text, que son más fáciles. Para usar. (), dos métodos. En la versión anterior, escribí una función para analizar el objeto de error y generar información de texto de retroalimentación.
15. El campo ManyToMany no se puede agregar ni eliminar. Por consideraciones de escalabilidad, se recomienda agregarlo de forma predeterminada. Puede agregar un campo date_added a la tabla de relaciones intermedia y agregar Unique_together. restricción por cierto, sin embargo, el uso es defectuoso: las operaciones de escritura son un poco engorrosas. Entonces, si no agregó y planea cambiarlo para agregarlo, ¿cuál debería ser la operación de cambio mínima? Primero debe eliminar el campo ManyToMany y hacer que la migración surta efecto, y luego agregar un campo ManyToMany con, por supuesto. , el fondo Los datos también se respaldan y revalidan. Esto debería considerarse como un defecto en la función actual de migración de Django.