Skip to content

Django Conceptos

scisneros edited this page May 30, 2022 · 1 revision

Conceptos de Django

En esta página resumiremos los principales conceptos de Django. Esto solo a modo de referencia. Para aprender a aplicar estos conceptos revisa la clase auxiliar.

Clase Auxiliar

Actividad

Clases en video:

Estructura

Los archivos más importantes son:

  • [proyecto]/manage.py: Este es el archivo con el que se corren los comandos del proyecto, como runserver, createsuperuser, migrate, etc.
  • [proyecto]/[proyecto]/settings.py: Define todas las variables de configuración del proyecto. Tengan cuidado al modificarlo.
  • [proyecto]/[proyecto]/urls.py: Asigna qué views o funciones se llamarán para cada URL del sitio.
  • [proyecto]/[app]/admin.py: Aquí se registran los modelos que quieren gestionar a través del admin de Django.
  • [proyecto]/[app]/models.py: Modelos de la base de datos, en forma de clases de Python.
  • [proyecto]/[app]/urls.py: Dentro de una app también pueden haber URLs específicas de esa app. Éstas deben importarse en el urls.py a nivel de proyecto.
  • [proyecto]/[app]/views.py: Funciones de Python que serán llamadas al recibir requests a las URLs asignadas.

Los archivos __init__.py son necesarios para que Python reconozca los módulos. Los archivos asgi.py y wsgi.py no son relevantes a este curso. El archivo test.py tampoco, pues no se esperan tests unitarios.

Apps

Una app en Django es un sub-módulo del proyecto que cumple alguna funcionalidad. Básicamente es un package de Python que sigue ciertas convenciones de Django.

El nombre app puede ser un poco confuso, pues da la impresión de que son una aplicación completa por sí solas, pero realmente más que como aplicaciones piénsenlas como módulos, como bloques de construcción para su proyecto. Por ejemplo, si su proyecto fuera U-Cursos, podrían tener una app para usuarios, otra para cursos, otra para foro, o una para horario, y cada app importa solo la data que necesita desde las otras apps. La división puede ser en términos de funcionalidad, de datos, de ubicación en el sitio web, de equipo de trabajo, o de cualquier criterio que ustedes estimen conveniente para organizar. Podrían tener todo su proyecto en una sola app, pero lo ideal sería separarlo en distintos módulos para mejorar la organización de su código.

La principal utilidad de tener las funcionalidades o secciones del proyecto en distintas apps es que mantiene su código más ordenado y mantenible, además de que la funcionalidad de una app podría reutilizarse en otros proyectos sin mayores migraciones.

Para crear una app se usa el comando

python manage.py startapp [nombre_de_app]

Esto creará un sub-directorio con el nombre de la app, como se indica en la sección Estructura. Luego se debe agregar el nombre de la app en la lista de INSTALLED_APPS ubicada en settings.py

Modelos y migraciones

Los models son una representación en Python de una base de datos. Con ellos, no es necesario hacer consultas de tipo SELECT FROM WHERE, sino que se usa el mismo lenguaje Python para consultar. Haciendo la analogía, cada model es una tabla, y cada columna de esa tabla es un field o campo en Django. Existen varios tipos de fields, como IntegerField, DatetimeField, CharField para tipos primitivos, y otros como ForeignKey y ManyToManyField, que representan llaves foráneas de la base de datos, para relacionar tablas entre sí. Pueden leer la documentación para saber más sobre los fields.

Las migraciones son una especie de control de versiones (como git), pero para la base de datos. Cada vez que hacen un cambio en la definición de un modelo (e.g. agregar un campo profesor al modelo Curso), es necesario crear una nueva "migración" usando python manage.py makemigrations, y luego para aplicar las migraciones creadas se debe usar python manage.py migrate.

Considera que makemigrations es análogo en git a hacer add para preparar los cambios, y migrate es como confirmar los cambios con un commit.

Views

Las views o vistas, a diferencia de lo que podría indicar el nombre, no son la parte visual del proyecto. Una view en Django es un controlador, la parte funcional del sistema. Acá es donde definen las funciones en Python que serán llamadas por el servidor cuando lleguen las requests de los clientes. Cada view debe siempre retornar algún tipo de HTTP Response, que es la respuesta que se enviará de vuelta al cliente. Esta respuesta puede ser solo data cruda (en el caso de un servidor API), pero en nuestro caso la respuesta implica renderizar un template, llenarlo con la data y enviar ya construida la página HTML completa que se mostrará al usuario.

Todo lo que ocurre en las views ocurre en el backend, es decir, en el computador que está corriendo el servidor de Django, por lo que acá puedes implementar cualquier funcionalidad que podrías hacer con el lenguaje Python, con la capacidad de tu servidor (tu computador).

Templates

Los templates sí son la parte visual de la aplicación. Son la forma en la que Django, un framework de backend/servidor, también puede servir como frontend. Están hechos en HTML (+ CSS y JavaScript), pero se mezclan con una sintáxis particular de Django ({% así %}) para poder incrustar data dinámicamente, construir la página y enviarla al cliente.

Los templates pueden incluir código JavaScript. Recuerden que JS es un lenguaje de cliente, por lo que se ejecuta en el computador del usuario y no en el servidor, con todas las limitaciones que ello implica.

URLs

En las URLs se define qué funciones (views) se llamarán según qué enlace está solicitando el usuario. Éstas pueden ser dinámicas, por ejemplo, la URL https://www.u-cursos.cl/ingenieria/2022/1/CC4401/1/integrantes le entrega como argumento dinámico a la view que estamos solicitando año=2022, semestre=1, curso=CC4401, sección=1. Luego la view puede usar estos argumentos para consultar la base de datos y filtrar los integrantes, para enviar la respuesta de vuelta.

Flujo

Juntando todos los conceptos, el flujo general de Django es el siguiente:

  • Usuario ingresa a una página, mediante una URL.
  • El servidor recibe la solicitud y chequea qué view le corresponde a dicha URL.
  • La view procesa la solicitud y realiza algún tipo de operación funcional con la data.
  • La view puede consultar la base de datos a través de los models.
  • La view incrusta y renderiza los datos obtenidos/procesados en un template en HTML.
  • Se envía una respuesta al cliente con la página HTML ya construida para mostrársela.