example - ¿Por qué SlugField() en Django?
slug url django (2)
Django tiene models.SlugField()
que nos ayuda a crear algunas URL geniales. Mi pregunta es por qué especificarlo como un campo
supongamos que tengo este modelo
class Blog(models.Model):
title = models.CharField()
y si quiero agregar slug, podría usar
class Blog(models.Model):
title = models.CharField()
def title_slug(self):
return slugify(self.title)
en las URL que podría usar
(r''^blog/(?P<id>/d+)/(?P<slug>[-/w]+)/$'', ''app.views.blog_view''),
y en vistas
def blog_view(request, id ,slug):
get_object_or_404(Blog, pk=id)
...
las URL se verán como
example.com/blog/23/why-iam-here/
Hay tres cosas que me hacen adoptar este método
- El campo Slug no viene con exclusividad implícita.
-
get_object_or_404(Blog, pk=id)
debe ser más rápido queget_object_or_404(Blog, slug=slug)
. - Agregar un campo slug a los modelos existentes implica la migración de datos.
¿por qué SlugField ()? , aparte del costo de generar dinámicamente slug, ¿cuáles son las desventajas del método anterior?
El campo Slug no viene con exclusividad implícita.
No hay exclusividad implícita con un CharField
. Debe especificar unique=True
si desea asegurarse de que cada fila sea única en el nivel de la base de datos. Debe hacer esto con un CharField
y un SlugField
por lo que no tiene ninguna ventaja
get_object_or_404 (Blog, pk = id) debe ser más rápido que get_object_or_404 (Blog, slug = slug).
Puede haber una pequeña diferencia debido a un índice en su clave principal, pero probablemente sea insignificante. SlugField
embargo, esto no tiene nada que ver con el uso de un CharField
vs SlugField
; acaba de crear una URL diferente que toma una id
y la usa para realizar la búsqueda.
Agregar un campo slug a los modelos existentes implica la migración de datos.
Agregar un CharField
a un modelo existente también requería una migración de datos, por lo que no hay ninguna ventaja aquí.
SlugFields
es simplemente CharField
con un poco de validación adicional. Mira el código . Estás rompiendo la regla de oro de Django: no te repitas.
Además, si solo usas un CharField
no obtienes ninguna validación en el nivel del formulario, por lo que puedes crear fácilmente un "slug" que no se ajuste a la validación de slugs, es decir, podría tener espacios o caracteres que no son permitido en una URL.
También con este enfoque, si cambias tu título, tu URL ha cambiado y ahora todos tus enlaces anteriores están muertos. Tener un campo slug evita esto.
Aquí está causando más problemas, solo use SlugField
¿Por qué SlugField () en Django? Porque:
- es amigable para los humanos (ej. / blog / en lugar de / 1 /).
- es un buen SEO para crear consistencia en título, título y URL.
¿La gran desventaja de tu slug generado dinámicamente, aceptar babosas en urls.py y no usar el slug para obtener el objeto correcto? Es un mal diseño.
Si suministras y aceptas babosas, pero no las compruebas, tienes varias URL que devuelven el mismo contenido. So / 1 / useful-slug / y / 1 / this-is-a-bs-slug / devolverán la misma página.
Esto es malo porque no hace la vida más fácil para los humanos. Sus visitantes deben proporcionar una identificación y algo que es redundante. Las páginas duplicadas son pesadillas en los motores de búsqueda. ¿Qué página es la correcta? Las páginas duplicadas terminarán con un rango bajo. Consulte https://support.google.com/webmasters/answer/40349?hl=en (última p)
Puede argumentar que implementa sus propios enlaces generados de manera consistente, pero las personas y los robots adivinan las URL todo el tiempo (vea sus archivos de registro). Cuando aceptas todas las babosas, los humanos y los bots siempre adivinan bien.
Además, guardar un slug en el db ahorra poder de procesamiento. Generas el slug una vez y lo vuelves a usar. ¿Qué será más (en) eficiente buscando la babosa o generando cada vez?
Los campos Slug en el administrador son útiles para dar a los editores la oportunidad de editar el slug. Tal vez para proporcionar información adicional que no está en el título, pero aún vale la pena mencionar.
Bonificación: para actualizar los datos migrados:
from django.template.defaultfilters import slugify
for obj in Blog.objects.filter(slug=""):
obj.slug = slugify(obj.title)
obj.save()