En esta segunda parte veremos algunos de los usos más interesantes de las class based views para presentar información y ahorrarnos trabajo. En concreto nos concentraremos en 

TemplateView

Como vimos en la primera parte TemplateView nos ahorra mucho trabajo si lo comparamos con la manera tradicionar de hacer las cosas. Sólo por el hecho de que ya se pasa el RequestContext ya recomendaría pasarnoas al nuevo mundo de las Class Based Views, pero os lo perdáis todavía hay más!

TemplateView incormpora dos métodos más get_context_data y get.  El método get lo que hace es llamar al método render_to_response que a su vez nos ha proporcionado el mixin TemplateResponseMixin pasándole como argumentos el diccionario que nos ha de devolver el método get_context_data.

Por defecto get_context_data nos retorna un diccionario con los parámetros que provienen de la url, así si nuestra url es:

 url(r'^test3/(?P<id>\d+)/$', Test3View.as_view(), 
    name="test3-class-view"),

entonces get_context_data contendría el diccionario i {'id': 3} y a la plantilla se pasará una variable llamada params con el contenido de este diccionaro. 

Supongamos por un momento que eso no es exactamente lo que deseamos. Queremos que se pase a la plantilla una variable llamada msg con un saludo para los lectores del blog. Lo que podemos hacer es sobreescribir get_context_data para que pase la información que queremos a la plantilla, de modo que nos quedaría:

class Test3View(TemplateView):
    template_name = 'main/index.html'

    def get_context_data(self, **kwargs):
        context = super(Test3View, self).get_context_data(**kwargs)
        context['id'] = self.kwargs.get('id')
        context['msg'] = u'Hello blog!'
        return context

para ser exactos, no haría falta llamar al método padre de  get_context_data y de hecho estamos pasando también la variable params, pero hacerlo así no nos hará mal y por otro lado nos proporciona un grado de protección mayor ante posibles problemas si un día decidimos que Test3View ya no heredará de TemplateView sinó de otra clase, que puede tener ya información en el contexto que nos interese.

En context_data podemos ir añadiendo toda la información que necesitemos. Conviene notar que estamos haciendo prácticamente lo mismo que cuando llamábamos al render_to_template con el método tradicional, sólo que ahora está todo mucho más estructurado.

Rizando el rizo

Supongamos ahora qu elo que queremos no es ya un mensaje fijo, sinó que éste se genera a partir del resultado de una función. Con el método antiguo tendríamos que crear una función en algún lado, unos lo podrían en un módulo aparte, otros com una función dentro de la vista. Ahora podemos aumentar el grado de cohesión de nuestro código encapsulando la funcionalidad dentro de un método de nuestra clase. Así:

class Test3View(TemplateView):
    template_name = 'main/index.html'

    def get_message(self):
        return u'Hello blog'

    def get_context_data(self, **kwargs):
        context = super(Test3View, self).get_context_data(**kwargs)
        context = dict()
        context['id'] = self.kwargs.get('id')
        context['msg'] = self.get_message()
        return context

Y para rematar, gracias al mixin TemplateResponseMixin podemos definir qué plantilla utilizar según nos convenga. Supongamos que el parámetro id nos sirve para definir el nombre de la plantilla, de modo que si existe una plantilla que case con este parámetro y si no que se presente la plantilla por defecto. Podríamos escribir un código como

class Test3View(TemplateView):
    template_name = 'main/index.html'

    def get_message(self):
        return u'Hello blog'

    def get_template_names(self):
        plantilla = 'main/index%s.html' % self.kwargs.get('id')
        return [plantilla, ] + super(Test3View, self).get_template_names()

    def get_context_data(self, **kwargs):
        context = super(Test3View, self).get_context_data(**kwargs)
        context['id'] = self.kwargs.get('id')
        context['msg'] = self.get_message()
        return context

Como se puede aprecier la potencia y flexibilidad que nos dan las Class Based Views no tienen nada que ver con lo que se podía hacer antes. Ahora tenemos más flexibilidad, más encapsulación y menos código que escribir.

 

Y en el próximo apunte hablaremos de formularios...

blog comments powered by Disqus