[AVISO] Turbogears 1.0, django, pylons

[Alberto Valverde]

> El Jueves, 4 de Enero de 2007 16:26, Alberto Valverde escribió:

> Esto es la comunidad de las listas de correo, pero la comunidad IRC (que
> yo
> tampoco sé mucho) se parece bastante más entre ambos framework. Turbogears
> 63, Pylons 51 usuarios conectados esta tarde.

Cierto, aunque es en la del correo dónde se suelen hacer los debates,
salen "recetas", dudas, etc... además, es más cómo buscar en sus archivos
que en los de IRC ;)

>> ¿Qué? ¿De dónde has sacado estos datos? Según unos benchmarks de
>> http://www.makotemplates.org/ (basados en otros que hay en algún
>> lugar del web de Genshi) la cosa queda así:
>>
>> Mako:	0.90 ms	    	Myghty:	5.25 ms
>> Cheetah:	0.70 ms		Genshi:	12.53 ms
>> Django:	5.43 ms		Kid:	19.12 ms
>>
>> Es decir, Cheetah es unas 6 veces más rápido que Django. Aunque
>> mirando los resultados en perspectiva el gran ganador es Mako al ser
>> puro python sin nada de C (¿Qué otra cosa se podía esperar del
>> creador de SQLAlchemy?). Lo de "no a la lógica dentro de las
>> plantillas" me parece muy bonito en teoría y algo a lo que se debe
>> aspirar, pero no estoy a favor de cortarle las alas intencionadamente
>> a los adultos responsables....
>>
> Probablemente tengas razón, yo estaba hablando de memoria. Lo que me
> extraña
> es que una aplicación en puro python sea más rápida que C, ¿no será al
> revés?
> La razón de que django lo haya considerado tan rápido es porque interpreta
> la
> plantilla usando regexp que están implementadas en C. django puede usar
> regexp porque tiene poca lógfica en las plantillas.

Quise decir que en terminos relativos: Mako parece tener más potencial que
Cheetah puesto que siendo python puro sólo es 20ms más lenta que Cheetah
la cual tiene extensiones en C.

Aunque ésto de los benchmarks también son muy relativos, puede que el
modelo empleado favoreza más a un lenguaje u otro... por ejemplo, había
casos Kid era bastante lento cuando había expresiones muy anidadas... O
también hay que tener en cuenta factores como que, aunque Clearsilver (por
ejemplo) es *muy* rápido (C puro) los benchmarks no suelen tener en cuenta
el tiempo que tarda python en generar el árbol HDL que le das de comer...
a lenguajes de python puros (o con extensiones C) les puedes pasar
generadores por ejemplo que "tiran" directamente de dónde haga falta
(resultados de una consulta, etc...). Resumiendo, mejor usar el que te
ahorre más tiempo a tí, no al procesador (que son más baratos)

>> > - Pylons permite usar varios módulos de plantillas incluso a la vez
>> > en la
>> > misma aplicación de forma muy fácil.
>>
>> Turbogears también. De hecho el interfaz que usa (Buffet) para
>> enchufarlos al framework lo inventó CP/TG.
>>
> Interesante puntualización.

¡Ah! y ToscaWidgets (mencionabas como integrable en Pylons) viene de TG...
:) No te extrañe ver en un futuro que ambos frameworks compartan varios
componentes... ("milagros" del WSGI)

>> > Yo, personalmente me estoy inclinando por Pylons y ya he hecho
>> > alguna prueba
>> > muy sencilla.
>>
>> Sabia elección. A mi parecer, la arquitectura de Pylons es la mejor
>> de los tres (espero que no me lean los de la lista... ;) lo que a mi
>> juicio es lo más importante a largo plazo para el futuro del
>> proyecto. Si tienes experiencia en python y desarrollo web en general
>> vas a estar muy a gusto ya que es un framework que, sin meterse
>> demasiado en tu camino, te desplega una estructura inicial muy solida
>> y bien diseñada donde tus aplicaciones podrán crecer a gusto. Por
>> otro lado, si no es el caso (el de la experiencia), tienes menos
>> tiempo, o la aplicación es más sencilla (no necesitas montar varias
>> aplicaciones independientes en el mismo proceso) probablemente
>> TurboGears te resultará más fácil ya que tienes más camino hecho. Si
>> vas a hacer algo de AJAX a mi jucio turbogears es mejor ya que la
>> salida de un mismo controlador la puedes reutilizar tanto para llenar
>> una plantilla como para serializarla en JSON.
>>
> Me acabas de hacer polvo, quiero usar AJAX a tope, pero me gusta más
> Pylons.

No te preocupes. Usa el que te sientas más cómodo con y te "entre" mejor
en la cabeza... y te ahorre más esfuerzo al venir más "de serie" con lo
que necesites.

En Pylons también es muy sencillo usar AJAX... si necesitas la
funcionalidad que mencioné (reutilizar el mismo método para salida JSON o
llenar plantilla) puedes implementarlo tú mismo en 20 líneas (ésto se
aplica también a bastantes otros aspectos de Pylons...). Por ejemplo, un
decorador parecido a éste:

# turbojson viene de TG pero es independiente, usa simplejson
# para codificar pero ofrece jsonify que es una función genérica
# que puedes especializar para que poder llamartla directamente con
# cualaquier objeto (descomponiéndolo en lo que acepta JSON: str, dict,
list, etc...)

from turbojson import jsonify


def permite_json(plantilla):
    def entangle(func):
        def permite_json(*args, *kw):
           o = func(*args, **kw)
           if pylons.request.is_xhr:
               # es una XMLHttpRequest, jsonificamos...
               return Response(jsonify(o))
           else:
               # No lo es, pasamos el diccionario que devolvió el método a
               # pylons.c y devolvemos la plantilla rellena
               for k, v in o.iteritems():
                   setattr(pylons.c, k, v)
               return render_response(plantilla)
        return permite_json
    return entangle

Ahora puedes escribir métodos en tus controladores que pueden ser llamados
desde una librería javascript (la que más te guste, MochiKit, jQuery...) y
manipularlos en el cliente o a la vieja usanza y recibir la misma
información en (x)html (que bonito es el MVC... ;) Basta con que los
decores con algo parecido a eso (deberías asegurarte de que se preserva la
signatura original, pylons tiene una fabrica de decoradores para eso...)

Un saludo,
Alberto