Vistas en Django: Funciones vs Clases y su Implementación
Contenido del curso
Sebastian Giraldo
Miguel Angel Reyes Moreno
Alvaro Eduardo Garzón Pira
Frandy De La Cruz
Alfredo Tzintzun
Mayra Alejandra Soto Nieto
Ray Trápala
Juan Camilo Grisales Arias
Henry Mauricio Cepeda Chacon
Daniel Buitrago
Brian Aurelio Alvarez Cuadros
David Agudelo
Daniel Alfredo García Serna
jesus manuel vergara arias
Luis Kennedy Saavedra Fuentes
Profe Luis, una recomendación o simplemente un comentario que considero importante: Una vez digas que resolvamos algo en una clase como mejora a la solución, pues debe resolverla usted también y mostrarla rápidamente en la clase posterior, de tal forma que aporte al conocimiento y mas importante aún que la aplicación que vemos en pantalla cuando explica no quede desactualizada y mejore la experiencia al estudiante en el aprendizaje.
En este caso en particular mira que el car_list todavía lo obtiene de una lista de diccionarios quemada y no de la BD sqlite como ya debería ir el ejercicio.
Muchas gracias y disculpe el atrevimiento
3 cosas: 1) Estoy parcialmente de acuerdo contigo. Proporcionar la solución puede ser bueno para los alumnos que más batallan con los ejercicios. Sin embargo, creo que estás viendo cómo usar Django, ya debes tener las bases sólidas de la programación bien entendidas, así como lo básico del frontend. 2) El punto es practicar y acostumbrarse a investigar y desbloquear la creatividad para resolver los problemas tú mismo 3) Hoy en día ya tenemos herramientas de IA que nos pueden asistir en los retos.
¡Hola! Estaba viendo esta clase y me quedaron dudas de como django encontraba el contexto para renderizar con la plantilla, ¿Por qué llamarlo get_context_data? La respuesta es porque al crear la clase CarListView, esta hereda de TemplateView, que a su vez, hereda de TemplateResponseMixin, ContextMixin y View, ContextMixin es la clase que tiene ese get_context_data y le dice que renderizar
Espero no se duplique el comentario.
Entonces estamos sobrescribiendo el metodo get_context_data que es heredado? quizas mas adelante se muestre como usarlo en lugar de sobrescribirlo
Así es, de forma resumida, se hereda el método y se sobrescribe, esto nos ayuda a que el código sea más limpio y reutilizable para cada CBV.
En Django, puedes crear vistas basadas en funciones (Function-Based Views, FBVs) o en clases (Class-Based Views, CBVs). Ambas tienen propósitos específicos y son útiles en diferentes contextos.
Vistas Basadas en Funciones (FBVs)
Son funciones simples que reciben una solicitud (request) y devuelven una respuesta (HttpResponse). Son más directas y fáciles de entender para tareas pequeñas y personalizadas.
Ventajas de FBVs:
Vistas Basadas en Clases (CBVs)
Son clases que representan vistas. Django ofrece vistas genéricas que implementan tareas comunes como listar, crear, actualizar o eliminar registros. Puedes extender estas clases o crear las tuyas propias.
Ventajas de CBVs:
veo que en las clases mencionan la sección de recursos pero no la encuentro, donde está?
La están haciendo aún.
x2
Mi recomendación aquí es que se acostumbren a utilizar clases, ya que en un entorno empresarial organizado siempre las vamos a ver entonces es importante irnos familiarizando con estas mismas.
Para poder recibir los valores pasados a la URL como en el caso de
path("<str:model>", CarDetailView.as_view())
en el CarDetailView se recibe así en el método get_context_data
class`` ``CarDetailView``(``TemplateView``): template_name = "myapp/car_detail.html"
``def`` get_context_data(``self``, **``kwargs``): return { "car": [car for car in Car.objects.filter(``title``=kwargs["model"])][0] }
¿Por qué es mejor usar clases aquí?
Las vistas basadas en clases (CBV) brillan cuando tu proyecto empieza a crecer. Imagina que tienes diez secciones diferentes en tu sitio web que necesitan mostrar una lista de elementos de la base de datos. Si usas funciones, tendrías que escribir la lógica de consulta y renderizado diez veces.
Al usar clases, puedes aprovechar el concepto de herencia de la programación orientada a objetos. Django ya te proporciona clases preconstruidas (como TemplateView o ListView) que manejan todo el trabajo pesado por detrás. Solo necesitas definir un par de variables, como el modelo que quieres consultar o el nombre del archivo HTML a renderizar. Esto hace que tu código sea mucho más limpio, modular y fácil de mantener. Además, si necesitas integrar herramientas de terceros, como un sistema de autenticación con redes sociales, la mayoría de estas librerías ya vienen empaquetadas como clases listas para ser integradas en tu proyecto.
📚 Nombre de la clase Vistas basadas en clases en Django
🎯 Idea principal Django permite crear vistas usando clases en lugar de funciones. Las Class-Based Views (CBV) permiten organizar mejor la lógica, reutilizar código y aprovechar la programación orientada a objetos para manejar solicitudes HTTP de forma más estructurada.
⚡ Síntesis en 10 segundos
🔑 Puntos clave
Vistas basadas en clases Alternativa a las vistas basadas en funciones que usa programación orientada a objetos.
Organización del código Permiten estructurar la lógica en métodos dentro de una clase.
Manejo de solicitudes HTTP Las clases pueden manejar diferentes tipos de solicitudes mediante métodos específicos.
Reutilización mediante herencia Se pueden extender o reutilizar comportamientos heredando de otras vistas.
Mayor escalabilidad Las CBV facilitan mantener aplicaciones grandes con lógica más estructurada.
🧠 Conceptos importantes
Class-Based View (CBV) Vista implementada como una clase que maneja solicitudes web.
Vista basada en función (FBV) Vista definida como una función simple que recibe una solicitud y devuelve una respuesta.
Herencia Principio de programación orientada a objetos que permite reutilizar comportamiento de una clase base.
Métodos HTTP Operaciones que representan acciones del cliente, como GET o POST.
🧩 Modelo mental de la clase
Solicitud del usuario ↓
Django dirige la solicitud a una vista basada en clase
↓
La clase identifica el método HTTP correspondiente
↓
Se ejecuta el método de la clase
↓
Se genera la respuesta
Las clases permiten organizar múltiples comportamientos dentro de una sola estructura lógica.
🚀 Acciones inmediatas
💼 Aplicación profesional
Las vistas basadas en clases son útiles en proyectos reales para:
Permiten mantener el código más organizado en aplicaciones grandes.
🔥 Hacks para la comunidad
Usar vistas basadas en funciones para lógica simple.
Usar vistas basadas en clases cuando la vista crece en complejidad.
Aprovechar la herencia para evitar repetir lógica entre vistas.
Mantener cada vista con una responsabilidad clara.
📝 Reflexión estratégica
Las vistas basadas en clases reflejan una evolución natural hacia arquitecturas más estructuradas y escalables.
Cuando los proyectos crecen, organizar la lógica mediante clases permite mantener el código más limpio, reutilizable y preparado para cambios futuros.
Aunque soy nuevo en Django, hoy vi la clase y me quedaron dudas sobre cómo pasar un parámetro a través del request. Al parecer, es necesario crear una función dentro de la clase. Pienso que cada clase tendría varias funciones asociadas, y estas se enviarían, en los casos respectivos a diferentes templates.
class AuthorProfileView(TemplateView): template_name = "my_first_app/author_profile.html" def get_context_data(self, **kwargs): context = super().get_context_data(**kwargs) author_id = self.kwargs.get('id') profile = Author.objects.get(id=author_id) context['author_profile'] = profile return context ```class AuthorProfileView(TemplateView): template\_name = "my\_first\_app/author\_profile.html" def get\_context\_data(self, \*\*kwargs): context = super().get\_context\_data(\*\*kwargs) author\_id = self.kwargs.get('id') profile = Author.objects.get(id=author\_id) context\['author\_profile'] = profile return context
Convertidores de ruta ¶
Los siguientes convertidores de ruta están disponibles de forma predeterminada:
str- Coincide con cualquier cadena que no esté vacía, excepto el separador de ruta '/'. Este es el valor predeterminado si no se incluye un convertidor en la expresión.int- Coincide con cero o cualquier entero positivo. Devuelve un int.slug- Coincide con cualquier cadena de caracteres que conste de letras o números ASCII, además de los caracteres de guión bajo y guion bajo. Por ejemplo, building-your-1st-django-site.uuid- Coincide con un UUID formateado. Para evitar que varias URL se asignen a la misma página, se deben incluir guiones y las letras deben estar en minúscula. Por ejemplo, 075194d3-6885-417e-a8a8-6c931e272f00. Devuelve una UUID")instancia.