¿Cuáles son las características de smashing (juego de palabras) de grok que lo hacen mejor que django? ¿cómo puedo saber cuándo mi proyecto necesita grok + zope, o simplemente puede desarrollarse con django?comparación grok vs. django
Respuesta
Zope fue el primer marco de publicación de objetos evah, y la comunidad Zope tiene una larga experiencia con Doing Things The Right Way. Zope 2 fue el primer intento, Zope 3 fue el siguiente intento, y ahora estamos en la tercera generación de frameworks web, que incluye Grok, BFG y Bobo.
Grok es enorme, y tiene aún más módulos disponibles que no vienen cuando instala la base (y está en el proceso de reducir también el número de módulos necesarios, por lo que la huella se hace más pequeña). BFG y Bobo van al revés, y son marcos minimalistas pero con fácil acceso a Zope Toolkit y todas las funcionalidades de Zope.
Y aunque Django está cometiendo muchos de los mismos errores que Zope2, también los están reparando mucho más rápido, así que espero que gran parte de esta discusión sea discutible en cinco años, porque espero que todos los frameworks de Python WSGI + WebOb + Repoze + Deliverance + Buildout como base para entonces. Pero incluso entonces iría por marcos en los que pueda usar Zope Component Architecture y ZODB, pero eso incluye no solo los realizados por la comunidad Zope, sino también, por ejemplo, Turbogears. Y tal vez también incluya a Django para entonces, quién sabe ... :-)
Dependiendo de cuáles sean los requisitos del proyecto, hoy elegiría Plone (si necesitan CMS), Grok o BFG (según el desarrolladores involucrados, y la complejidad de la tarea y el presupuesto).Esto, por supuesto, depende en parte de mi gran experiencia con las tecnologías Zope y mi pequeña experiencia con Django, pero principalmente porque puedo usar ZTK y ZODB en Grok y BFG.
YMMV, etc., blahblah.
- Zope Toolkit
- Brandon hablar sobre la arquitectura de componentes de Zope (Video from PyCOn, Slides from PloneConf)
- BFG
- Bobo
No creo que ninguno de los frameworks tenga alguna 'característica' que lo haga a uno 'mejor' que el otro, o 'necesario' en ciertas circunstancias. Por el contrario, la diferencia entre Django y Grok - o Pylons, o Turbogears - es realmente una de enfoque. Puede encontrar el enfoque de Grok a su gusto, o puede preferir uno de los otros. Dudo que haya mucho que puedas lograr en uno de ellos que no puedas en ninguno de los otros.
Grok es básicamente todo el poder de zope en un paquete mucho más fácil de usar. Así que obtienes todo el lujo de una base de datos de objetos python real (aunque puedes usar un back-end sql). Y supongo que conoce los adaptadores/utilidades/vistas de la llamada "arquitectura de componentes zope". Esos permiten hacer una aplicación robusta. Especialmente útil si luego necesita personalizarlo selectivamente. Y la seguridad es tradicionalmente un punto fuerte zope (y grok). El desarrollo y la implementación se manejan completamente con eggs (y buildout): en mi experiencia, esta es una manera robusta, confiable, repetible y cómoda.
Si tiene una aplicación que puede trabajar con tablas SQL directas sin necesidad de mucha personalización selectiva después: nada malo con django. Tendrás que hacer mucha seguridad tú mismo, así que eso requiere un buen ojo. Hay mucho menos marco detrás de esto (un ORM y un mapeador de url), por lo que su pitón se sentirá más "puro y simple". Esto también significa que necesitas hacer más tú mismo.
No hay nada que le impida utilizar selectivamente partes de grok: http://pypi.python.org/pypi/grokcore.component, por ejemplo, es el núcleo. Muy bien aislado, así que puedes usarlo sin comprar todo el zope stack. Estoy bastante seguro de que puedes usar eso en django. El componente grokcore/zope es solo código python. Esto le proporciona los adaptadores/interfaces/utilidades. No sé lo que estás construyendo, así que tendrás que experimentar.
Una cosa muy a favor de grok que sugeriría probar: base de datos de objetos ZODB de zope. Un buen ORM (y el de django está bastante bien) ayuda mucho a sacar el dolor de las bases de datos SQL, pero una base de datos de objetos real es sencillamente de lujo :-)
- 1. Django -vs- Grails -vs-?
- 2. ¿Django grok YML? django no carga los archivos YML (yml no es una serialización conocida)
- 3. Comparación PyQt vs PySide
- 4. Comparación Haskell vs. Prolog
- 5. Comparación: LINQ vs LAMBDA Expresión
- 6. Operadores de comparación Ruby? == vs. ===
- 7. Django - Django reglas de comparación de permisos Django y utilizando
- 8. Django-nonrel vs Django-mongodb vs Mongokit vs pymongo native
- 9. django-pyodbc vs django-mssql
- 10. Comparación: métodos de interfaz vs métodos virtuales vs métodos abstractos
- 11. pruebas de Silverlight: Watin vs comparación selenio
- 12. Java vs. Comparación de velocidad de PHP
- 13. Comparación detallada de ICEfaces vs RichFaces?
- 14. comparación de la secuencia: == operador() vs. Iguales()
- 15. Comparación de rendimiento de Derby vs PostgreSql
- 16. hash() vs. crypt() función de comparación
- 17. Comparación del empadronador vs iteratee paquete
- 18. Comparación de cadenas: InvariantCultureIgnoreCase vs OrdinalIgnoreCase?
- 19. C# Tipo Comparación: Type.Equals vs == operador
- 20. ZBar vs. zxing - Comparación de reconocimiento QR
- 21. Comparación de cadenas usando == vs strcmp
- 22. Comparación de cadenas en .Net: "+" vs "-"
- 23. Django CharField vs TextField
- 24. django-signals vs triggers?
- 25. Django vs PHP + marco
- 26. Django filter vs exclude
- 27. Django RESTful API - django-piston vs. django-tastypie
- 28. MongoEngine vs MongoKit para Django
- 29. Python Django vs ASP.NET MVC
- 30. ForeignKey vs OneToOne campo django
Lo que me impresiona es el tamaño de grok + zope con respecto a Django. Entonces me pregunto. ¿Qué pasa si necesito algo que está allí, pero por el momento no sé? –
Luego, escríbela para Django, es de código abierto. –