• ROOT_URLCONF identifica el módulo Python donde están definidos los patrones de URL de la aplicación.
• DATABASES es un diccionario que contiene la configuración de nuestra base de datos. Debe haber siempre una base de datos por defecto. La configuración predefinida hace uso de una base de datos SQLite3.
• LANGUAGE_CODE define el idioma por defecto para nuestro sitio web.
• USE_TZ le indica a Django que tenga en cuenta el huso horario definido en caso de estar activo. Esta variable viene activa cuando se crea el proyecto usando startproject.
Esta es una visión general de algunas de las variables de configuración más importantes. Se detallará su utilidad a lo largo de los capítulos de este libro.
Proyectos y aplicaciones
En este libro podrá encontrar muchas menciones a los términos proyecto y aplicación. En Django, un proyecto se considera una instalación Django incluyendo su configuración. Mientras que una aplicación es un conjunto de modelos, vistas, plantillas y patrones de URL con cierta entidad independiente. Las aplicaciones interactúan con el framework Django para proveer de funcionalidad específica y pueden reutilizarse en diferentes proyectos. Se puede pensar en el proyecto como el sitio web, mientras que una aplicación es un blog, una wiki, un foro o un chat, que conforman el sitio web y pueden reutilizarse a su vez en diferentes sitios web.
Crear una aplicación
Se va a crear la primera aplicación Django y construir un blog desde cero. Para ello se ejecuta, desde la raíz del proyecto, el siguiente comando:
Esto creará la estructura principal de una aplicación, que tiene la siguiente jerarquía de ficheros:
A continuación, se dispone de:
• admin.py, que es el fichero donde se registran los modelos para que sean incluidos en el sitio de administración de Django. Hacer uso del sitio de administración de Django no es obligatorio.
• apps.py, que contiene la configuración principal de la aplicación blog.
• migrations, que es un directorio que contendrá las migraciones de base de datos de la aplicación. Esto permite que Django haga un seguimiento de los cambios en los modelos de datos y que puedan sincronizarse con la base de datos de forma coherente.
• models.py, que contiene los modelos de datos de la aplicación. Toda aplicación de Django requiere de un fichero models.py, pero el fichero puede estar vacío.
• tests.py, que es donde se incluirán los test de la aplicación.
• views.py contiene la lógica de la aplicación. Cada vista recibe una petición HTTP, la procesa y devuelve una respuesta.
Esquema de datos del blog
Se va a comenzar por el diseño del esquema de datos del blog definiendo los modelos. Un modelo es una clase Python que hereda de django.db. models.Model, en la que cada atributo representa un campo de base de datos. Por cada uno de los modelos que se ha definido en el fichero models.py Django creará una tabla en la base de datos. A través de estos modelos, Django ofrece una API que permite realizar acciones sobre objetos de la base de datos de manera sencilla.
Para comenzar, se va a definir un modelo Post. Para ello se debe añadir las siguientes líneas en el fichero models.py de la aplicación blog:
Este es el modelo de datos para los artículos del blog. Los campos que se acaban de definir en el modelo son los siguientes:
• title es un campo que contiene el título del artículo y es de tipo CharField, lo que se traduce en una columna de tipo VARCHAR en la base de datos.
• slug es un campo utilizado para la generación de la URL para el artículo. Es una cadena de texto que puede estar formada por letras, números, guiones medios y/o bajos. Se utilizará este campo para construir URLs amigables y aptas para el SEO del sitio web. Se ha incluido el parámetro unique_for_date a este campo para poder añadir también a la URL la fecha de publicación del artículo. De este modo, Django prevendrá de tener múltiples artículos con el mismo slug para la misma fecha.
• author es una clave foránea que define una relación uno a muchos. De esta forma se indica a Django que un artículo está escrito por un usuario y que, a su vez, un usuario puede ser autor de muchos artículos. Django creará esta relación en la base de datos utilizando la clave primaria del modelo al que se hace referencia, en este caso, el modelo User del sistema de autenticación del framework. El parámetro on_delete especifica el comportamiento que debe tener el artículo cuando el objeto referenciado es eliminado. Esto no es específico de Django sino de la base de datos. Si se usa el valor CASCADE, al eliminar un autor se eliminarán también todos los artículos del blog asociados a este. Para el resto de opciones disponibles puede encontrar más información en https://docs.djangoproject.com/en/2.0/ref/models/fields/#django.db.models.ForeignKey.on_delete. Para especificar el nombre de la relación inversa (de User a Post), se utiliza el parámetro related_name. Esto nos permitirá acceder de manera sencilla a los objetos desde el modelo User.
• body contiene el cuerpo del artículo. Este campo es de tipo texto, el cual se convierte en una columna TEXT en lenguaje SQL de base de datos.
• publish es un campo de tipo fecha y hora que indica el momento de publicación del artículo. Por defecto, se usa el valor now del módulo timezone de Django. Este devuelve el momento actual según el huso horario en que se haya definido nuestro proyecto.
• created, al igual que publish, es un campo de tipo fecha y hora, pero que indica el momento de creación del artículo. Haciendo uso de auto_now_add, el valor se guardará automáticamente en la creación del objeto sin tener que especificarlo de forma explícita.
• updated es también un campo de fecha y hora. Como su nombre indica, muestra el momento del último cambio que sufrió el objeto. Para ello, se emplea auto_now, que actualizará automáticamente este valor.
• status es un campo tipo texto que contendrá los estados en los que puede estar el artículo. Haciendo uso del parámetro choices se limita el valor de status a una lista finita de valores.
Django ofrece una amplia variedad de tipos de campos para construir los modelos. En https://docs.djangoproject.com/en/2.0/ref/models/fields/ se puede encontrar una lista completa de todos los que hay disponibles.
La clase Meta dentro del modelo define metadatos del propio modelo. En este caso se indica a Django que, por defecto, cuando se realice una consulta sobre este modelo en base de datos, ordene los resultados por el campo publish en orden descendente. Esto último, se especifica con el prefijo menos. De este modo, los artículos más recientes aparecerán primero.
