35
Aprendiendo Django #2
En el post anterior vimos muy por arriba las configuraciones
Por eso hoy, quiero profundizar un poco mas en ello.
Por eso hoy, quiero profundizar un poco mas en ello.
Comencemos...
En el archivo de settings definimos todo: debug mode, conexion a la base de datos, aplicaciones en funcionamiento en el proyecto, etc.
Todo esto es definido mediante simples variables que Django utiliza y que, por lo tanto, se convierten en palabras claves.
Estas son algunas de las mas importantes:
Estas son algunas de las mas importantes:
Se trata de una cadena de caracteres que es usada para crear una firma criptografica.
django-admin startproject nos genera una SECRET_KEY de forma random que podemos reemplazar con lo que queramos.Recordemos que las firmas criptograficas deben ser unicas e impredecibles, y no deben ser expuestas puesto que con ellas los datos se encriptan en la base de datos. De hecho, el sitio oficial del proyecto nos advierte de lo siguiente:
Se trata de una variable booleana que permite alternar entre el modo de produccion y el modo debug en nuestro proyecto.
Los escenarios son los siguiente:
Como dijimos anteriormente, es una lista que contiene todas las IPs que pueden hacer peticiones a nuestro proyecto.
Se trata de una lista de todas las aplicaciones habilitadas dentro de nuestro proyecto.
Cada vez que instalamos un paquete (como DjangoRestFramework) o creamos nosotros mismos una aplicacion, debemos de agregar su "ruta" de forma manual.
Por ejemplo, si creamos una aplicacion llamada "posts" podemos indicarlo asi:
Cada vez que instalamos un paquete (como DjangoRestFramework) o creamos nosotros mismos una aplicacion, debemos de agregar su "ruta" de forma manual.
Por ejemplo, si creamos una aplicacion llamada "posts" podemos indicarlo asi:
INSTALLED_APPS = [
# ... aplicaciones que ya estaban
'posts'
]O asi:
INSTALLED_APPS = [
# ... aplicaciones que ya estaban
'posts.apps'
]Este ultimo hace referencia a un archivo de configuracion presente en todas las aplicaciones que creamos/instalamos:
apps.pySPOILER ALERT: es un error muy comun olvidar incorporar la aplicacion al listado y perder horas revisando por que Django no ejecuta las migraciones 😅
Segun wikipedia: "El middleware es todo software que se sitúa entre el sistema operativo y las aplicaciones que corren sobre él"
Tomando esta idea, dentro de Django los middlewares no son mas que porciones de codigo reutilizables que funcionan entre las peticiones del cliente y el proyecto.
Django nos provee de los mas comunes, pero esto no quita que podamos crear nuevos middlewares personalizados que se ajusten a nuestros requerimientos.
Es una cadena de caracteres que le indica a Django cual es el archivo principal que agrupara todas las URLs disponibles en el proyecto.
Lista que contiene las configuraciones para trabajar con plantillas HTML.
Cada configuracion debe indicarse como un diccionario.
Cada configuracion debe indicarse como un diccionario.
Es una cadena de caracteres que le indica a Django donde se encuentra el archivo de configuracion para correr nuestro proyecto.
No es mas que un diccionario donde definimos las configuraciones pertinentes para conectar nuestro proyecto con una base de datos.
Por defecto, Django trae una configuracion para usar SQLite3 pero si deseamos usar otro motor, bastaria con modificar este diccionario.
Por defecto, Django trae una configuracion para usar SQLite3 pero si deseamos usar otro motor, bastaria con modificar este diccionario.
Por ejemplo, esto es para usar PostgreSQL:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'my_database',
'USER': 'user',
'PASSWORD': 'password',
'HOST': '127.0.0.1',
'PORT': 5432,
}
}Es una lista que contiene diccionarios, que contienen los scripts a ejecutar para validar las contraseñas (longitud, similaridad con los datos de usuario, contraseñas comunes, etc.).
Si bien son varias variables, no quiero crear un item por cada una cuando el proposito de todas ellas es el mismo.
35