DEV Community

Cover image for Aprendiendo Django #2
Leonel G.
Leonel G.

Posted on

Aprendiendo Django #2

En el post anterior vimos muy por arriba las configuraciones
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:

SECRET KEY 🔐

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:

Advertencia de Django

DEBUG 🐛

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:

Si DEBUG es False 🚫

  • El proyecto respondera a los errores con respuestas genericas ante problemas HTTP-4XX o HTTP-5XX
  • El proyecto verificara si la IP de la fuente que solicita acceso a los recursos se encuentra dentro de ALLOWED_HOST, y en caso negativo, rechazara la peticion.

Si DEBUG es True ✅

  • El proyecto respondera con mucha mas informacion acerca de los errores HTTP-4XX o HTTP-5XX, otorgandonos informacion del error, el traceback de ejecucion, contenido de las variables al momento del error, informacion de la configuracion (a excepcion de variables con los nombres 'API', 'KEY', 'PASS', 'SECRET', 'SIGNATURE' o 'TOKEN' por obvias razones), y por ultimo, informacion de la peticion
  • Dado que el modo DEBUG se encuentra activo, Django permitira que cualquier IP pueda hacer peticiones.

ALLOWED_HOSTS 💻

Como dijimos anteriormente, es una lista que contiene todas las IPs que pueden hacer peticiones a nuestro proyecto.

INSTALLED_APPS 📦

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:

INSTALLED_APPS = [
    # ... aplicaciones que ya estaban
    'posts'
]
Enter fullscreen mode Exit fullscreen mode

O asi:

INSTALLED_APPS = [
    # ... aplicaciones que ya estaban
    'posts.apps'
]
Enter fullscreen mode Exit fullscreen mode

Este ultimo hace referencia a un archivo de configuracion presente en todas las aplicaciones que creamos/instalamos: apps.py

SPOILER ALERT: es un error muy comun olvidar incorporar la aplicacion al listado y perder horas revisando por que Django no ejecuta las migraciones 😅

MIDDLEWARE 🧱

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.

ROOT_URLCONF 🛃

Es una cadena de caracteres que le indica a Django cual es el archivo principal que agrupara todas las URLs disponibles en el proyecto.

TEMPLATES 📃

Lista que contiene las configuraciones para trabajar con plantillas HTML.
Cada configuracion debe indicarse como un diccionario.

WSGI_APPLICATION 💻

Es una cadena de caracteres que le indica a Django donde se encuentra el archivo de configuracion para correr nuestro proyecto.

DATABASES 📚

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 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,
    }
}
Enter fullscreen mode Exit fullscreen mode

AUTH_PASSWORD_VALIDATORS 🔍

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.).

INTERNATIONALIZATION 🌎

Si bien son varias variables, no quiero crear un item por cada una cuando el proposito de todas ellas es el mismo.

  • LANGUAGE_CODE: define el lenguaje en el que se desplegaran los mensajes o la informacion en el proyecto, como asi tambien en el panel de administracion.
  • TIME_ZONE: define la zona horaria
  • USE_I18N: define si habilitar o no el sistema de traduccion de Django
  • USE_L10N: define si debe formatear o no los datos de localizacion. Si es True, mostrará números y fechas usando el formato de la configuración de la region actual

Discussion (0)