[pyar] Separación de lógica y presentación en Django

[Ramiro Morales]

2010/9/7 Federico Heinz <fheinz en vialibre.org.ar>:
> On 07/09/2010, Ale wrote:
>> una que se me ocurre es que hagas un filtro[0] de django que haga
>> justamente lo que haría get_class()
>> <td class={{ foo|get_class }}>...
>
> Suena plausible... pero no estamos de nuevo rompiendo alguna
> aislación? (aunque ya ni sé muy bien en qué parte del sistema se
> considera que están los template tags).

Coincido con vos sobre que 'idealísticamente' esomno debería estar en
el modelo. Algunos escenarios que justificaría esto: La DB se va
a usar co otros frontends no-web, o es una DB heredada.

El tema con los templates Django (que determinan cómo se ve la info)
es que no te ofrecen la forma de definir ni la 'fórmula' que te
determina los valores de SOMETHING ni una estructura de datos
en la cual almacenar los mismos pre-calculados.

O sea que eso nos lleva a que tengas que extender el template con
código Python como te sugiere Ale o moverlo a la vista Django (que
define qué info se ve).

Si elegis este camino una idea sería convertir directamente tu queryset
a una lista de diccionarios Python en la vista llamando a
bar.values('type', 'name')
y a esos diccionarios inyectarles un key e.g. 'clase' con el valor del
nombre de la clase CSS correspondiente antes de enviar bar al
template. Todo esto para poder usar:

<td class="{{ foo.clase }}">{{foo.name}}</td>

La desventaja que tiene esto de manejar los valores de .type en models
y sus correspondientes clases CSS en otro lugar es que tenes que
recordar mantener ambos sincronizados en models.py y views.py
(o tu biblioteca de template filters) cada vez que modifiques el primero.

-- 
Ramiro Morales  |  http://rmorales.net