Debido a que Django fue desarrollado en un ambiente de sala de redacción de ritmo rápido, fue diseñado para hacer tareas comunes de desarrollo web de forma rápida y fácil. Aquí se incluye una introducción informal de cómo escribir una aplicación web que utiliza una base de datos con Django.
\nEl objetivo de este documento es darle suficiente información técnica para entender cómo funciona Django, pero no pretende ser un tutorial o referencia - ¡Aunque tenemos ambas cosas! Cuando esté listo para empezar un proyecto con Django, puede comenzar con el tutorial o: doc:doc:ir directamente a la documentación más detallada </topics/index>.
\nAunque es posible usar Django sin una base de datos, Django cuenta con un mapeador objeto-relacional en el que es posible definir la estructura de la base de datos utilizando código Python.
\nLa sintaxis de modelo de datos ofrece muchas formas de representar sus modelos – hasta ahora, ha resuelto una cantidad equivalente a años de problemas de esquemas de base de datos. Aquí hay un ejemplo rápido:
\nfrom django.db import models\n\nclass Reporter(models.Model):\n full_name = models.CharField(max_length=70)\n\n def __str__(self):\n return self.full_name\n\nclass Article(models.Model):\n pub_date = models.DateField()\n headline = models.CharField(max_length=200)\n content = models.TextField()\n reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)\n\n def __str__(self):\n return self.headline\nNext, run the Django command-line utilities to create the database tables\nautomatically:
\nLinux / macOS
$ python manage.py makemigrations\n$ python manage.py migrate\nWindows
...\\> py manage.py makemigrations\n...\\> py manage.py migrate\nThe makemigrations command looks at all your available models and\ncreates migrations for whichever tables don’t already exist. migrate\nruns the migrations and creates tables in your database, as well as optionally\nproviding much richer schema control.
With that, you’ve got a free, and rich, Python API\nto access your data. The API is created on the fly, no code generation\nnecessary:
\n# Import the models we created from our "news" app\n>>> from news.models import Article, Reporter\n\n# No reporters are in the system yet.\n>>> Reporter.objects.all()\n<QuerySet []>\n\n# Create a new Reporter.\n>>> r = Reporter(full_name='John Smith')\n\n# Save the object into the database. You have to call save() explicitly.\n>>> r.save()\n\n# Now it has an ID.\n>>> r.id\n1\n\n# Now the new reporter is in the database.\n>>> Reporter.objects.all()\n<QuerySet [<Reporter: John Smith>]>\n\n# Fields are represented as attributes on the Python object.\n>>> r.full_name\n'John Smith'\n\n# Django provides a rich database lookup API.\n>>> Reporter.objects.get(id=1)\n<Reporter: John Smith>\n>>> Reporter.objects.get(full_name__startswith='John')\n<Reporter: John Smith>\n>>> Reporter.objects.get(full_name__contains='mith')\n<Reporter: John Smith>\n>>> Reporter.objects.get(id=2)\nTraceback (most recent call last):\n ...\nDoesNotExist: Reporter matching query does not exist.\n\n# Create an article.\n>>> from datetime import date\n>>> a = Article(pub_date=date.today(), headline='Django is cool',\n... content='Yeah.', reporter=r)\n>>> a.save()\n\n# Now the article is in the database.\n>>> Article.objects.all()\n<QuerySet [<Article: Django is cool>]>\n\n# Article objects get API access to related Reporter objects.\n>>> r = a.reporter\n>>> r.full_name\n'John Smith'\n\n# And vice versa: Reporter objects get API access to Article objects.\n>>> r.article_set.all()\n<QuerySet [<Article: Django is cool>]>\n\n# The API follows relationships as far as you need, performing efficient\n# JOINs for you behind the scenes.\n# This finds all articles by a reporter whose name starts with "John".\n>>> Article.objects.filter(reporter__full_name__startswith='John')\n<QuerySet [<Article: Django is cool>]>\n\n# Change an object by altering its attributes and calling save().\n>>> r.full_name = 'Billy Goat'\n>>> r.save()\n\n# Delete an object with delete().\n>>> r.delete()\nOnce your models are defined, Django can automatically create a professional,\nproduction ready administrative interface –\na website that lets authenticated users add, change and delete objects. The\nonly step required is to register your model in the admin site:
\nfrom django.db import models\n\nclass Article(models.Model):\n pub_date = models.DateField()\n headline = models.CharField(max_length=200)\n content = models.TextField()\n reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)\nfrom django.contrib import admin\n\nfrom . import models\n\nadmin.site.register(models.Article)\nThe philosophy here is that your site is edited by a staff, or a client, or\nmaybe just you – and you don’t want to have to deal with creating backend\ninterfaces only to manage content.
\nUn flujo de trabajo típico en la creación de aplicaciones Django es crear modelos y poner a funcionar los sitios administrativos lo más rápido posible para que su personal (o clientes) puedan empezar a ingresar los datos y luego, perfeccionar la forma como los datos se presentan al público.
\nUn esquema de URL limpio y elegante es un detalle importante en una aplicación web de alta calidad. Django fomenta un diseño de URL hermoso y no añade ningún elemento innecesario en las URLs, como .php o .asp.
To design URLs for an app, you create a Python module called a URLconf. A table of contents for your app, it contains a mapping\nbetween URL patterns and Python callback functions. URLconfs also serve to\ndecouple URLs from Python code.
\nAsí es como se vería una URLconf para el ejemplo Reporter/Article anterior:
from django.urls import path\n\nfrom . import views\n\nurlpatterns = [\n path('articles/<int:year>/', views.year_archive),\n path('articles/<int:year>/<int:month>/', views.month_archive),\n path('articles/<int:year>/<int:month>/<int:pk>/', views.article_detail),\n]\nEl código anterior mapea las URLs a funciones callback de Python («vistas»). Las cadena de caracteres de la ruta usa etiquetas para «capturar» los valores de las URLs. Cuando un usuario solicita una página Django pasa por cada patrón en orden y se detiene en el primero que coincide con la URL solicitada. (Si ninguno de ellos coincide Django llama una vista del caso especial 404). Esto es increíblemente rápido debido a que las rutas son compiladas como expresiones regulares en tiempo de carga.
\nUna vez que una de las expresiones regulares coincide, Django llama a la vista determinada, que es una función Python. Cada vista recibe un objeto de consulta – que contiene metadatos de consulta – y los valores capturados en la expresión regular.
\nPor ejemplo si un usuario solicitara la dirección URL «/articles/2005/05/39323/» Django llamaría la función news.views.article_detail(request, year=2005, month=05, pk=39323).
Cada vista es responsable de hacer una de dos cosas: retornar un objeto HttpResponse que incluye el contenido de la página solicitada, o levantar una excepción como Http404. El resto depende de usted.
Generalmente, una vista recupera los datos de acuerdo con los parámetros, carga una plantilla y crea la plantilla con los datos recuperados. Aquí está una vista de ejemplo para el year_archive de arriba:
from django.shortcuts import render\n\nfrom .models import Article\n\ndef year_archive(request, year):\n a_list = Article.objects.filter(pub_date__year=year)\n context = {'year': year, 'article_list': a_list}\n return render(request, 'news/year_archive.html', context)\nEste ejemplo utiliza el sistema de plantillas de Django que tiene varias características potentes, pero se esfuerza por mantenerse lo suficientemente simple como para que los que no son programadores lo puedan utilizar.
\nEl código anterior carga la plantilla news/year_archive.html.
Django tiene una ruta de búsqueda de plantillas lo que le permite a usted minimizar la redundancia entre las plantillas. En su configuración de Django, usted especifica una lista de directorios para verificar si hay plantillas con DIRS. Si una plantilla no existe en el primer directorio, verifica en el segundo y así sucesivamente.
Digamos que se encontró la plantilla news/year_archive.html`. Así es como podría verse:
\n{% extends "base.html" %}\n\n{% block title %}Articles for {{ year }}{% endblock %}\n\n{% block content %}\n<h1>Articles for {{ year }}</h1>\n\n{% for article in article_list %}\n <p>{{ article.headline }}</p>\n <p>By {{ article.reporter.full_name }}</p>\n <p>Published {{ article.pub_date|date:"F j, Y" }}</p>\n{% endfor %}\n{% endblock %}\nLas variables están rodeadas por llaves dobles. {{ article.headline }} significa «Enviar el valor del atributo headline del artículo». Sin embargo, los puntos no sólo se utilizan para las operaciones de búsqueda de atributo. También pueden hacer búsqueda de pares diccionario-clave, búsqueda de índice y llamadas a funciones.
Tenga en cuenta que {{ article.pub_date|date:"F j, Y" }} utiliza una «tubería» al estilo Unix (el carácter «|»). Esto se conoce como filtro de plantilla, y es una manera de filtrar el valor de una variable. En este caso, el filtro de fecha formatea un objeto datetime de Python en el formato determinado (como se encuentra en la función de fecha de PHP).
Usted puede encadenar tantos filtros como desee. Usted puede escribir filtros de plantillas personalizados. Usted puede escribir etiquetas de plantillas personalizadas que ejecutan el código Python personalizado tras bastidores.
\nPor último, Django usa el concepto de «herencia de plantillas». Eso es lo que hace el {% extends "base.html"%}. Esto quiere decir «Primero cargue la plantilla llamada “base”, que ha definido un grupo de bloques, y llene los bloques con los siguientes bloques.» En resumen, eso le permite reducir drásticamente la redundancia en las plantillas: cada plantilla tiene que definir sólo lo que es exclusivo de esa plantilla.
Aquí esta como la plantilla «base.html», incluyendo el uso de static files, podría verse:
\n{% load static %}\n<html>\n<head>\n <title>{% block title %}{% endblock %}</title>\n</head>\n<body>\n <img src="{% static 'images/sitelogo.png' %}" alt="Logo">\n {% block content %}{% endblock %}\n</body>\n</html>\nSimplistically, it defines the look-and-feel of the site (with the site’s logo),\nand provides «holes» for child templates to fill. This means that a site redesign\ncan be done by changing a single file – the base template.
\nIt also lets you create multiple versions of a site, with different base\ntemplates, while reusing child templates. Django’s creators have used this\ntechnique to create strikingly different mobile versions of sites by only\ncreating a new base template.
\nTenga en cuenta que usted no tiene que usar el sistema de plantillas de Django si prefiere otro sistema. Si bien el sistema de plantillas de Django está particularmente bien integrado con la capa modelo de Django, nada lo obliga a usarlo. No tiene tampoco que usar la API de base de datos de Django. Puede usar otra capa de abstracción de base de datos, leer archivos XML, leer archivos desde el disco o lo que desee. Cada parte de Django – modelos, vistas, plantillas – está separada de la otra.
\nEsta ha sido solamente una rápida introducción a la funcionalidad de Django. Otras características útiles:
\nUn framework de caché que se integra con memcached u otros backends.
A syndication framework that lets you\ncreate RSS and Atom feeds by writing a small Python class.
More attractive automatically-generated admin features – this overview\nbarely scratched the surface.
The next steps are for you to download Django, read the tutorial and join the community. Thanks for your interest!
\n