2009-03-31 30 views
59

Probé prácticamente todos los frameworks web de Python que existen, y me llevó mucho tiempo darme cuenta de que no había un marco de bala de plata, cada uno tenía sus propias ventajas y desventajas. Comencé con Snakelets y disfruté sinceramente de poder controlar casi todo en un nivel inferior sin mucho alboroto, pero luego descubrí TurboGears y lo he estado utilizando (1.x) desde entonces. Herramientas como Catwalk y la consola web son invaluables para mí.Django vs otros frameworks web de Python?

Pero con TurboGears 2 que salen, que trae soporte WSGI, y después de leer sobre los debates religiosos entre los campos de Django y WSGI, realmente estoy dividido entre "haciendo de la manera correcta", por ejemplo, aprendiendo WSGI, pasando un valioso tiempo escribiendo funcionalidades que ya existen en Django y otros frameworks completos, en lugar de usar Django o algún framework de alto nivel que hace todo por mí. Las desventajas con este último que puedo ver son bastante obvias:

  1. no estoy aprendiendo nada en el proceso
  2. Si alguna vez tengo que hacer nada menor nivel que va a ser un dolor
  3. El La sobrecarga requerida para solo un sitio básico que usa autenticación es una locura. (OMI)

lo tanto, supongo que mi pregunta es, cuál es la mejor opción, o es sólo una cuestión de opinión, y debería aguantar y utilizar Django si logra lo que quiera con un mínimo esfuerzo (¿Quiero autenticación y una interfaz CRUD para mi base de datos)? Intenté con Werkzeug, Glashammer y mis amigos, pero AuthKit y Repoze me asustaron, así como la cantidad de pasos necesarios para configurar la autenticación básica. Miré a Pylons, pero la documentación parece faltar, y al hacer referencia a funciones simples como la autenticación o una interfaz CRUD, varias páginas wiki y documentación parecían contradecirse entre sí, con diferentes hacks para versiones y demás.


Gracias a S. Lott por señalar que no era lo suficientemente claro. Mi pregunta es: ¿cuál de las siguientes opciones vale la pena a largo plazo, pero no es dolorosa a corto plazo (por ejemplo, una especie de término medio, ¿alguien?) - ¿Aprender WSGI o seguir con un marco de "baterías incluidas"? En este último caso, agradecería una sugerencia acerca de si debería volver a intentar con Django, atenerme a TurboGears 1.x o aventurarme en algún otro marco.

Además, probé CherryPy, pero parecía que no podía encontrar una aplicación CRUD suficientemente buena que pudiera utilizar inmediatamente.

+0

¿Podría aclarar su pregunta? "¿Cuál es la mejor opción" entre qué opciones? Django vs. TurboGears 1 vs. TurboGears 2? Por favor aclare para que sepamos lo que realmente está preguntando y qué ayuda realmente necesita. –

Respuesta

15

Sugiero echar otro vistazo a TG2. Creo que las personas no han notado algunos de los avances que se han realizado desde la última versión. Además de la creciente pila WSGI de utilidades disponibles, hay bastantes elementos específicos de TG2 a considerar. Aquí hay un par de aspectos más destacados:

TurboGears Administration System - Esta interfaz CRUD para su base de datos es totalmente personalizable utilizando una clase de configuración declarativa. También está integrado con Dojo para brindarte tablas infinitamente desplazables. La validación del lado del servidor también está automatizada. La interfaz de administración utiliza URLs RESTful y verbos HTTP lo que significa que sería fácil conectarse mediante programación utilizando los estándares de la industria.

CrudRestController/RestController - TurboGears proporciona una forma estructurada de manejar los servicios en su controlador. Brindarle la capacidad de utilizar verbos HTTP estandarizados simplemente ampliando nuestro RestController. Combine Sprox con CrudRestController, y puede colocar crud en cualquier lugar de su aplicación con formularios autogenerados totalmente personalizables. TurboGears ahora admite mime-types como extensiones de archivo en la url, por lo que puede hacer que su controlador muestre .json y .xml con la misma interfaz que utiliza para procesar html (devolver un diccionario desde un controlador)

Si hace clic En los enlaces, verá que tenemos un nuevo conjunto de documentación creado con sphinx que es más extenso que los documentos del pasado.

Con la mejor web server, ORM y template system (s) (elija su propia) bajo el capó, es fácil ver por qué TG tiene sentido para las personas que quieren ponerse en marcha rápidamente, y todavía tienen escalabilidad como su sitio crece .

TurboGears a menudo se considera como tratar de alcanzar un objetivo en movimiento, pero somos coherentes con los lanzamientos, lo que significa que no tendrá que preocuparse por trabajar fuera del maletero para obtener las últimas funciones que necesita. Próximamente: más extensiones de TurboGears que permitirán a su aplicación aumentar la funcionalidad con la facilidad de los comandos de pasadores.

+1

técnicamente no tuve ningún problema con Turbogears. Pero encontré la comunidad elitista y menos útil para los recién llegados que Rails/Django/web2py. – hoju

7

Has echado un vistazo a CherryPy. Es minimalista, pero eficiente y simple. Es lo suficientemente bajo como para que no se interponga en su camino, pero lo suficientemente alto como para ocultar la complejidad. Si recuerdo bien, TurboGears fue construido en él.

Con CherryPy, tiene la opción de mucho más. (Marco de plantilla, ORM si se quiere, back-end, etc.)

21

Yo diría que estás siendo demasiado pesimista sobre "no aprender nada" usando Django o un framework de pila completa similar, y subestimando el valor de la documentación y una gran comunidad. Incluso con Django todavía hay una curva de aprendizaje considerable; y si no hace todo lo que quiere, no es que el código de la infraestructura sea impenetrable.

Alguna experiencia personal: Pasé años, intermitentemente, jugando con Twisted/Nevow, TurboGears y algunos otros frameworks web de Python.Nunca terminé nada porque el código del marco estaba permanentemente inacabado y se reescribía debajo de mí, la documentación a menudo no existía o era incorrecta y el único soporte viable era a través de IRC (donde a menudo recibía buenos consejos, pero sentía que era imponente si también lo pedía muchas preguntas).

En comparación, en los últimos años he eliminado algunos sitios con Django. A diferencia de mi experiencia previa, en realidad están implementados y en ejecución. El proceso de desarrollo de Django puede ser lento y cuidadoso, pero resulta en mucho menos bitrot y desaprobación, y la documentación que es realmente útil.

Soporte de autenticación HTTP para Django finally went in hace unas semanas, si eso es lo que te refieres en el n. ° 3.

+0

¿Cómo se compara repoze.bfg en términos de documentación, soporte, acabado-toque, etc.? –

2

¿Has echado un vistazo a web2py? Después de evaluar recientemente muchos frameworks web de Python recientemente, decidí adoptar este. También consulte Google App Engine si aún no lo ha hecho.

1

Django definitivamente vale la pena aprender, y parece que se ajustará a sus propósitos. La interfaz de administración que viene con es fácil de poner en marcha, y usa autenticación.

En cuanto a "cualquier nivel inferior", si se refiere a sql, es completamente posible meter sql en sus consultas con la palabra clave adicional. Estilísticamente, siempre intenta evitar eso tanto como sea posible.

En cuanto a "no aprender nada" ... la verdadera pregunta es si su preferencia es aprender principalmente algo de nivel inferior o superior, lo cual no es una pregunta que alguien aquí pueda responder por usted.

0

Soy un fan de TurboGears, y esta es exactamente la razón por la cual: una muy buena compensación entre el control y hacer las cosas bien frente a fácil.

Tendrá que decidirse por supuesto. Tal vez prefieras aprender menos, tal vez más. Tal vez las áreas que me gustan el conocimiento/control (base de datos, por ejemplo), no podría importarle menos. Y no entiendas mal. No estoy caracterizando ningún framework como necesariamente difícil o incorrecto. Es solo mi juicio subjetivo.

También recomendaría TurboGears 2 si es posible. Cuando salga, creo que será mucho mejor que 1.0 en términos de lo que ha seleccionado para los valores predeterminados (genshi, pilones, SqlAlchemy)

0

Sugeriría para TurboGears 2. Han hecho un trabajo fantástico integrando mejor del mundo de Python.

WSGI: Asumiendo que está desarrollando proyectos moderadamente complejos/soluciones comerciales en TG2 o en algún otro marco, diga Grok. A pesar de que estos marcos son compatibles con WSGI, ¿eso significa que alguien que está utilizando estos marcos debe aprender WSGI? En la mayoría de los casos, la respuesta es No. Quiero decir que es bueno tener este conocimiento sin dudas.

conocimiento WSGI es, probablemente, es más útil en casos como

  • desea utilizar alguna de middleware o algún otro componente que no está prevista como parte de la pila estándar para, por ejemplo. Authkit con TG o Grok without ZODB.
  • estás haciendo algo de integración.

CherryPy es bueno, pero pensar en el manejo de su base de datos confirma/reversiones al final de las operaciones, la exposición de JSON, validaciones en tales casos TG, Django como marcos hacen todo por ti.

+2

CherryPy es más pitónico, si sigues la regla del zen (http://www.python.org/dev/peps/pep-0020/): explícito es mejor que implícito., Simple es mejor que complejo. No soy fanático de la magia detrás de las escenas, como compromisos y retrocesos. – Martin

11

Su pregunta parece ser "¿vale la pena aprender WSGI y hacer todo usted mismo?", O utilizar un "marco de pila completo que hace todo por usted".

Diría que es una dicotomía falsa y que hay una tercera vía obvia. TurboGears 2 intenta proporcionar una ruta sin problemas desde un marco de estilo "haz todo por ti" hasta una comprensión del middleware WSGI, y la capacidad de personalizar casi todos los aspectos del marco para satisfacer las necesidades de tu aplicación.

Es posible que no tengamos éxito en todos los lugares y en todos los niveles, pero especialmente si ya tiene experiencia en TurboGears 1, creo que la curva de aprendizaje TG2 será muy fácil al principio y tendrá la capacidad de profundiza exactamente cuando lo necesites.

Para hacer frente a sus problemas particulares:

  • proporcionamos un sistema de autorización de la caja que coincide con la que está acostumbrado a partir de TG1.
  • Proporcionamos una interfaz tipo "admin django" lista para usar llamada tgext.admin, que funciona muy bien con dojo para hacer que una hoja de cálculo de lujo como la interfaz sea la predeterminada.

También me gustaría abordar algunas de las otras opciones que existen y hablar un poco sobre los beneficios.

  • CherryPy. Creo que CherryPy es un excelente servidor web y un buen marco web minimalista. No está basado en WSGI internamente, pero tiene una buena compatibilidad con WSGI, aunque no le proporcionará la experiencia de "pila completa". Pero para las configuraciones personalizadas que deben ser rápidas y no son particularmente adecuadas para los valores predeterminados proporcionados por Django o TurboGears, es una gran solución.

  • Django. Creo que Django es un sistema muy bueno y totalmente integrado para desarrollar sitios web. Si su aplicación y estilo de trabajo se ajustan bien a su configuración estándar, puede ser fantástico. Sin embargo, si necesita ajustar el uso de su base de datos, reemplazar el lenguaje de plantilla, usar un modelo de autorización de usuario diferente o hacer las cosas de otra manera, es muy probable que se encuentre luchando contra el marco.

  • Pilones Pilones como CherryPy es un gran marco web minimalista. A diferencia de CherryPy, está habilitado para WSGI a través de todo el sistema y proporciona algunos valores predeterminados correctos, como SQLAlchemy y Mako, que pueden ayudarte a escalar bien. Los nuevos documentos oficiales son de mucha mejor calidad que los viejos documentos wiki que parecen haber visto.

53

los debates religiosos entre los campos de Django y WSGI

Parecería como si estuviera un poco poco confundido acerca de lo que es y lo que WSGI es Django. Decir que Django y WSGI están compitiendo es como decir que C y SQL están compitiendo: estás comparando manzanas y naranjas.

Django es un framework, WSGI es un protocolo (que es compatible con Django) de cómo el servidor interactúa con el framework. Lo más importante, aprender a usar WSGI directamente es un poco como aprender a ensamblar. Es una gran experiencia de aprendizaje, pero en realidad no es algo que deba hacer para el código de producción (ni estaba destinado a serlo).

En cualquier caso, mi consejo es que lo resuelva por usted mismo. La mayoría de los marcos tienen un ejercicio tipo "hacer una wiki/blog/encuesta en una hora". Pase un poco de tiempo con cada uno y descubra cuál le gusta más. Después de todo, ¿cómo puedes decidir entre diferentes marcos si no estás dispuesto a probarlos?

+12

+1 para abordar el error de django/wsgi tan claramente –

6

Aprender WSGI

WSGI es absurdamente sencilla .. Es básicamente una función que parece ..

def application(environ, start_response) pass 

La función se llama cuando se recibe una petición HTTP. environ contiene varios datos (como el URI de solicitud, etc.), start_response es una función invocable, que se utiliza para establecer encabezados.

El valor devuelto es el cuerpo del sitio web.

aplicación def (environ, start_response): start_response ("200 OK", []) retorno "..."

Eso es todo lo que hay que hacer, de verdad .. No es un marco, pero más un protocolo para marcos web para usar ..

Para la creación de sitios, usando WSGI es no la manera "correcta" - con ayuda de los marcos existentes es .. pero, si está escribiendo una web marco de Python a continuación, utilizando WSGI es absolutamente la manera correcta ..

El marco que usas (CherryPy, Django, TurboGears, etc.) es básicamente una preferencia personal. Juega en cada uno, mira cuál te gusta más y luego úsalo. Hay una pregunta de StackOverflow (con una gran respuesta) sobre esto, "Recommendation for straight-forward python frameworks"

2

Yo diría que la respuesta correcta depende de lo que realmente quiere y necesita, ya que lo que valdrá la pena en el largo plazo depende de lo que necesite en a largo plazo. Si su objetivo es lograr que las aplicaciones se implementen lo antes posible, entonces la ruta 'más simple', es decir. Django, seguramente es el camino a seguir. El valor de un sistema bien probado y bien documentado que exactamente lo que desea no puede ser subestimado.

Por otro lado, si tiene tiempo para aprender una variedad de cosas nuevas que pueden aplicarse en otros dominios y desea tener el mayor alcance para la personalización, algo como Turbogears es superior. Turbogears te ofrece la máxima flexibilidad, pero tendrá y tendrás que pasar mucho tiempo leyendo documentos externos para cosas como Repoze, SQLAlchemy y Genshi para hacer algo útil con él. Los documentos TG2 son deliberadamente menos detallados que los documentos TG1 en algunos casos porque se considera que los documentos externos son mejores de lo que solían ser. Si este tipo de cosas es un obstáculo o una inversión depende de sus propios requisitos.

1

Pilones parece una gran herramienta para mí:

  • un marco web real (CherryPy es sólo un servidor web),
  • pequeña base de código - reutilización de otros proyectos,
  • escrito completamente con WSGI en cuenta, en base a pegar,
  • le permite codificar la aplicación de inmediato y toca los bits de bajo nivel si es necesario,

tengo usó CherryPy y TurboGears y observó muchos otros frameworks, pero ninguno de ellos era tan ligero y productivo como Pylons. Compruebe el presentation at Google.

-1

Web2py es la salsa secreta aquí. No te pierdas echarle un vistazo.

Cuestiones relacionadas