python - examples - ¿Cómo funcionan exactamente los tipos de contenido de Django?

django templates examples

Question

Realmente estoy teniendo dificultades para comprender el concepto de los tipos de contenido de Django. Se siente muy hackish y, en última instancia, en contra de cómo Python tiende a hacer las cosas. Dicho eso, si voy a usar Django, entonces tengo que trabajar dentro de los límites del marco.

Así que vengo aquí preguntándome si alguien puede dar un ejemplo práctico del mundo real sobre cómo funciona un tipo de contenido y cómo lo implementaría. Casi todos los tutoriales (principalmente en blogs) que he revisado no hacen un gran trabajo cubriendo realmente el concepto. Parecen retomar el lugar donde quedó la documentación de Django (lo que parece no ser el caso).

Answer 1

¿Desea utilizar el marco de Tipos de contenido en su trabajo?

Comience haciéndose esta pregunta: "¿Alguno de estos modelos debe relacionarse de la misma manera con otros modelos y / o reutilizaré estas relaciones de formas imprevistas más adelante en el futuro?" La razón por la que hacemos esta pregunta es porque esto es lo que hace mejor el marco de tipos de contenido: crea relaciones genéricas entre los modelos. Bla, bla, veamos un poco de código y veamos a qué me refiero.

# ourapp.models
from django.conf import settings
from django.db import models
# Assign the User model in case it has been "swapped"
User = settings.AUTH_USER_MODEL
# Create your models here
class Post(models.Model):
author = models.ForeignKey(User)
title = models.CharField(max_length=75)
slug = models.SlugField(unique=True)
body = models.TextField(blank=True)
class Picture(models.Model):
author = models.ForeignKey(User)
image = models.ImageField()
caption = models.TextField(blank=True)
class Comment(models.Model):
author = models.ForeignKey(User)
body = models.TextField(blank=True)
post = models.ForeignKey(Post)
picture = models.ForeignKey(Picture)

Está bien, entonces tenemos una manera de crear teóricamente esta relación. Sin embargo, como programador de Python, su intelecto superior le dice que esto es una mierda y que puede hacerlo mejor. ¡Cinco altos!

¡Ingrese al marco de tipos de contenido!

Bueno, ahora vamos a ver de cerca nuestros modelos y volver a trabajarlos para ser más "reutilizables" e intuitivos. Comencemos por deshacernos de las dos claves externas en nuestro modelo de Comment y reemplácelas por una GenericForeignKey .

# ourapp.models
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType
...
class Comment(models.Model):
author = models.ForeignKey(User)
body = models.TextField(blank=True)
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = GenericForeignKey()

¿Entonces qué pasó? Bueno, entramos y agregamos el código necesario para permitir una relación genérica con otros modelos. Observe que hay más que solo un GenericForeignKey , sino también una ForeignKey para ContentType y un PositiveIntegerField para el object_id . Estos campos son para decirle a Django con qué tipo de objeto está relacionado y qué ID es para ese objeto. En realidad, esto tiene sentido porque Django necesitará ambos para buscar estos objetos relacionados.

Bueno, eso no es muy parecido a Python ... ¡es algo feo!

Probablemente estés buscando un código hermético, impecable e intuitivo que enorgullezca a Guido van Rossum . Te entiendo Miremos el campo GenericRelation para que podamos ponerle un GenericRelation lazo a esto.

# ourapp.models
from django.contrib.contenttypes.fields import GenericRelation
...
class Post(models.Model):
author = models.ForeignKey(User)
title = models.CharField(max_length=75)
slug = models.SlugField(unique=True)
body = models.TextField(blank=True)
comments = GenericRelation(''Comment'')
class Picture(models.Model):
author = models.ForeignKey(User)
image = models.ImageField()
caption = models.TextField(blank=True)
comments = GenericRelation(''Comment'')

Bam! Solo así puedes trabajar con los Comentarios para estos dos modelos. De hecho, sigamos adelante y hagamos eso en nuestro shell (escriba python manage.py shell desde su directorio de proyecto Django).

>>> from django.contrib.auth import get_user_model
>>> from ourapp.models import Picture
# We use get_user_model() since we are referencing directly
User = get_user_model()
# Grab our own User object
>>> me = User.objects.get(username=''myusername'')
# Grab the first of our own pictures so we can comment on it
>>> pic = Picture.objects.get(author=me)
# Let''s start making a comment for our own picture
>>> pic.comments.create(author=me, body="Man, I''m cool!")
# Let''s go ahead and retrieve the comments for this picture now
>>> pic.comments.all()
[<Comment: "Man, I''m cool!">]

Es así de simple.

¿Cuáles son las otras implicaciones prácticas de estas relaciones "genéricas"?

Las claves externas genéricas permiten relaciones menos intrusivas entre varias aplicaciones. Por ejemplo, supongamos que sacamos el modelo de comentarios a su propia aplicación llamada chatterly . Ahora queremos crear otra aplicación llamada noise_nimbus donde las personas almacenan su música para compartir con los demás.

¿Qué pasa si queremos agregar comentarios a esas canciones? Bueno, podemos dibujar una relación genérica:

# noise_nimbus.models
from django.conf import settings
from django.contrib.contenttypes.fields import GenericRelation
from django.db import models
from chatterly.models import Comment
# For a third time, we take the time to ensure custom Auth isn''t overlooked
User = settings.AUTH_USER_MODEL
# Create your models here
class Song(models.Model):
''''''
A song which can be commented on.
''''''
file = models.FileField()
author = models.ForeignKey(User)
title = models.CharField(max_length=75)
slug = models.SlugField(unique=True)
description = models.TextField(blank=True)
comments = GenericRelation(Comment)

Espero que hayan encontrado esto útil, ya que me hubiera encantado encontrar algo que me mostrara la aplicación más realista de los campos GenericForeignKey y GenericRelation .

¿Es esto demasiado bueno para ser verdad?

Como con cualquier cosa en la vida, hay pros y contras. Cada vez que agrega más código y más abstracción, los procesos subyacentes se hacen más pesados ​​y un poco más lentos. Agregar relaciones genéricas puede agregar un poco de un amortiguador de rendimiento a pesar de que intentará almacenar en caché inteligente sus resultados. Con todo, todo se reduce a si la limpieza y la simplicidad superan las pequeñas ganancias de rendimiento. Para mí, la respuesta es un millón de veces sí.

Hay más en el marco de tipos de contenido que he mostrado aquí. Existe un nivel completo de granularidad y uso más detallado, pero para la persona promedio, así es como lo utilizará 9 de cada 10 veces, en mi opinión.

Relacionadores genéricos (?) ¡Cuidado!

Una advertencia bastante grande es que cuando usa una GenericRelation , si se GenericRelation el modelo que tiene GenericRelation aplicada ( Picture ), también se eliminarán todos los objetos relacionados ( Comment ). O al menos en el momento de escribir esto.

Answer 2

Bien, la respuesta directa a su pregunta: (del código fuente de django) es: Tipos de medios de análisis según RFC 2616, sección 3.7.

¿Cuál es la manera más desgarbada de decir que lee / permite-a-modificar / pasa a lo largo del encabezado httpd ''Tipo de contenido'' .

Sin embargo, está pidiendo un ejemplo más de uso de práctica. Tengo 2 sugerencias para ti:

1: examine este código

def index(request):
media_type=''text/html''
if request.META.has_key(''CONTENT_TYPE''):
media_type = request.META[''CONTENT_TYPE''].split('';'')[0]
if media_type.lower() == ''application/json'':
return HttpResponse("""{ "ResponseCode": "Success"}""", content_type="application/json; charset=UTF-8")
return HttpResponse("<h1>regular old joe</h1>");

2: recuerda que django es python y, como tal, ejerce el poder de la comunidad python. Hay 2 plugins increíbles de RESTFul para django. Entonces, si quieres ver qué tan profundo se va el conejo, puedes echarle un vistazo.

• Marco de descanso django
• tastypie

Sugiero pasar por el tutorial django-rest-framework, que tratará específicamente sobre "actuar en diferentes contenidos / tipos". Nota: Es una práctica común usar el encabezado de tipo de contenido para ''descansar'' las API relajadas .