A pesar que el termino vista puede interpretarse de una forma, en Django esto no es el concepto clásico que manejamos para la misma, por ejemplo en la programación web muchas veces el resultado que nos arroja una vista depende de las acciones del usuario, tal vez el usuario actualiza un desplegable y cambia el sentido total de la vista.
Cuando intentamos establecer el concepto de vista, lo que queremos lograr es no tratar de compararlo al concepto que podamos tener predefinido de otros entornos MVC, una vez que tenemos el concepto de vista de Django podemos expresarlo de mejor forma a otros desarrolladores.
El esqueleto de la Vista
Si vemos el cuerpo de la vista y nos vamos hasta los cimientos del mismo podemos decir que una vista es una función que toma una petición HTTP y retorna una respuesta HTTP, pudiéramos decir que este enfoque peca de simple, sin embargo si vemos la finalidad de la vista este concepto lo cumple adecuadamente, ahora que para llegar a la simpleza de estos dos elementos debemos realizar otras actividades.
Vistas Genéricas
La filosofía de Django nos indica que debemos hacer todo lo posible para que nuestras aplicaciones sean re-utilizables, simples y efectivas, que quiere decir esto, que no podemos desarrollar elementos repetitivos, es decir, escribir el mismo código una y otra vez ya que no tiene sentido, veamos la siguiente imagen:
En este código estamos viendo como construimos una función, esta función nos representa una vista, sin embargo dista mucho de ser una solución que cumpla los puntos de la filosofía Django, si bien es cierto que el código funciona y en muchos casos haría el trabajo más que bien, imaginemos que en vez de tener que hacer solo esa vista tengamos que hacer 100 o 200 porque tenemos una aplicación de grandes proporciones, tendríamos que repetir esta lógica una y otra vez, generando el mismo tipo de código.
Si nos fijamos, el nombre de la vista, los parámetros que llama, inclusive la respuesta que da, que es dirigir hacia una URL predefinida por el desarrollador, todo esto nos apunta a una vista especifica y no genérica.
Antes que nos podamos preocupar, ya el framework tiene una solución a este problema y es nada más y nada menos que las vistas genéricas, estás son vistas que ya están definidas, solamente tenemos que unirles un modelo, indicar una plantilla y podemos acceder a funciones y métodos que hacen todo lo básico que debemos tener.
Veamos el código de estas vistas genéricas en la siguiente imagen:
En el ejemplo podemos notar varios puntos interesantes, primero no limitamos la función a un solo modelo, vemos como utilizamos la función model.get_default_manager con el cual establecemos cual es la llave primaria de nuestro modelo, luego retornamos el nombre de la plantilla que primero obtuvimos como argumento de la función.
Aquí ya no tenemos limitación por código, ya que esto está hecho una sola vez y lo incluye Django, solo debemos preocuparnos por integrar lo que vayamos a utilizar, veamos la implementación de una vista utilizando este enfoque:
En nuestra implementación simplemente llamamos a la función show_object de la clase views, indicamos que modelo utilizará y el nombre de la plantilla, algo mucho menos repetitivo y más sencillo que el enfoque no genérico que vimos al inicio.
Como pudimos ver, tenemos herramientas dentro del framework que nos ahorran trabajo y además podemos cumplir con una filosofía de desarrollo limpia y eficiente al disminuir el número de líneas de código innecesarias que escribimos.
Cuando intentamos establecer el concepto de vista, lo que queremos lograr es no tratar de compararlo al concepto que podamos tener predefinido de otros entornos MVC, una vez que tenemos el concepto de vista de Django podemos expresarlo de mejor forma a otros desarrolladores.
El esqueleto de la Vista
Si vemos el cuerpo de la vista y nos vamos hasta los cimientos del mismo podemos decir que una vista es una función que toma una petición HTTP y retorna una respuesta HTTP, pudiéramos decir que este enfoque peca de simple, sin embargo si vemos la finalidad de la vista este concepto lo cumple adecuadamente, ahora que para llegar a la simpleza de estos dos elementos debemos realizar otras actividades.
Vistas Genéricas
La filosofía de Django nos indica que debemos hacer todo lo posible para que nuestras aplicaciones sean re-utilizables, simples y efectivas, que quiere decir esto, que no podemos desarrollar elementos repetitivos, es decir, escribir el mismo código una y otra vez ya que no tiene sentido, veamos la siguiente imagen:
En este código estamos viendo como construimos una función, esta función nos representa una vista, sin embargo dista mucho de ser una solución que cumpla los puntos de la filosofía Django, si bien es cierto que el código funciona y en muchos casos haría el trabajo más que bien, imaginemos que en vez de tener que hacer solo esa vista tengamos que hacer 100 o 200 porque tenemos una aplicación de grandes proporciones, tendríamos que repetir esta lógica una y otra vez, generando el mismo tipo de código.
Si nos fijamos, el nombre de la vista, los parámetros que llama, inclusive la respuesta que da, que es dirigir hacia una URL predefinida por el desarrollador, todo esto nos apunta a una vista especifica y no genérica.
Antes que nos podamos preocupar, ya el framework tiene una solución a este problema y es nada más y nada menos que las vistas genéricas, estás son vistas que ya están definidas, solamente tenemos que unirles un modelo, indicar una plantilla y podemos acceder a funciones y métodos que hacen todo lo básico que debemos tener.
Veamos el código de estas vistas genéricas en la siguiente imagen:
En el ejemplo podemos notar varios puntos interesantes, primero no limitamos la función a un solo modelo, vemos como utilizamos la función model.get_default_manager con el cual establecemos cual es la llave primaria de nuestro modelo, luego retornamos el nombre de la plantilla que primero obtuvimos como argumento de la función.
Aquí ya no tenemos limitación por código, ya que esto está hecho una sola vez y lo incluye Django, solo debemos preocuparnos por integrar lo que vayamos a utilizar, veamos la implementación de una vista utilizando este enfoque:
En nuestra implementación simplemente llamamos a la función show_object de la clase views, indicamos que modelo utilizará y el nombre de la plantilla, algo mucho menos repetitivo y más sencillo que el enfoque no genérico que vimos al inicio.
Como pudimos ver, tenemos herramientas dentro del framework que nos ahorran trabajo y además podemos cumplir con una filosofía de desarrollo limpia y eficiente al disminuir el número de líneas de código innecesarias que escribimos.
