Antonio Melé - Django 2

Para arrancar el servidor de desarrollo solo se necesita escribir desde un intérprete el siguiente comando. Es importante que se haga desde la raíz del proyecto:

La salida debería ser similar a:

Acceda a la URL http://127.0.0.1:8000/desde un navegador. Debería ver una página similar a la siguiente, indicando que el proyecto funciona correctamente:

La imagen anterior refleja que Django está en funcionamiento. Si se mira la consola en la que se ejecuta el servidor, se puede ver una petición GET realizada por el navegador:

Esta petición HTTP es registrada por el servidor de desarrollo en la consola. Cualquier error que se produzca durante la ejecución también se verá aquí.

El servidor de desarrollo de Django admite cierta configuración. Puede indicarle un host y puerto específicos o que cargue una configuración diferente del siguiente modo:

En el caso de que disponga de diferentes entornos en los que desplegar la aplicación, es una buena práctica disponer de un fichero de configuración por entorno.

Es importante recordar que este servidor está solo pensado para su uso durante el desarrollo y que en ningún caso debe utilizarse para un entorno de producción. Para desplegar la aplicación Django en un entorno real se debe de ejecutar como una aplicación WSGI sobre un servidor web como Apache, Gunicorn o uWSGI. Puede obtener más información sobre cómo realizar esta tarea con Django en https://docs.djangoproject.com/en/2.0/howto/deployment/wsgi/.

En el capítulo 13 , Lanzamiento en producción , se explica cómo configurar un entorno de producción real para sus proyectos Django.

Toda la configuración del proyecto se encuentra en el fichero settings.py. Por defecto, durante la creación del mismo, Django incluye en este fichero información relevante que permite arrancar el proyecto, pero en él solo hay una parte de todas las variables que puede llegar a tener. Puede encontrar información sobre todas las variables de configuración y sus posibles valores en https://docs.djangoproject.com/en/2.0/ref/settings/.

A continuación, se repasan las principales variables de configuración:

• DEBUG es una variable booleana que activa o desactiva el modo de depuración en nuestro proyecto. Si está activo (con valor True), Django mostrará una página de error con la traza e información de contexto en caso de excepciones no tratadas. Cuando se despliega sobre un entorno de producción esta variable debe tener valor False. En caso contrario, se expone información sensible del proyecto.

• ALLOWED_HOSTS no se aplica cuando DEBUG está activo o cuando se ejecutan los test. Una vez se mueva el proyecto a un entorno de producción y se desactive la variable DEBUG, se deberá también añadir un dominio o host para poder servir la aplicación.

• INSTALLED_APPS es una variable que será necesario modificar en todos los proyectos y contiene información de las aplicaciones que están activas para cada uno de ellos. Por defecto, Django incluye en esta variable las siguientes aplicaciones:

○ django.contrib.admin: sitio de administración

○ django.contrib.auth: aplicación de autenticación

○ django.contrib.contenttypes: aplicación para la gestión de content types

○ django.contrib.sessions: aplicación de sesiones

○ django.contrib.messages: aplicación de mensajes

○ django.contrib.staticfiles: aplicación para la gestión de contenido estático

• MIDDLEWARE es una lista que contiene las capas intermedias que se ejecutarán.

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

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.

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.