Quelles sont les caractéristiques fracassantes (chrynudiques) de grok qui le rend mieux que django? Comment puis-je savoir quand mon projet a besoin de Grok + Zope, ou il peut simplement être développé avec Django?
3 Réponses :
Je ne pense pas que les cadres sont destinés à avoir des "fonctionnalités" qui font "mieux" que l'autre, ou "nécessaire" dans certaines circonstances. Plutôt la différence entre Django et Grok - ou Pylônes, ou turbogears - est vraiment une approche. Vous trouverez peut-être l'approche de Grok à votre goût, ou vous préférerez peut-être l'un des autres. Je doute qu'il y ait beaucoup que vous pouvez réaliser dans l'un d'entre eux que vous ne pouvez dans aucun des autres.
Ce qui me impressionne est la taille de Grok + Zope par rapport à Django. Alors je me demande. Et si j'ai besoin de quelque chose que c'est là, mais pour le moment je ne sais pas?
Ensuite, écrivez-le pour Django - c'est une source ouverte.
Grok est essentiellement toute la puissance de Zope d'une manière plus facile à utiliser. Vous obtenez donc tout le luxe d'une vraie base de données d'objet Python (bien que vous puissiez utiliser un backend SQL). Et je suppose que vous connaissez les adaptateurs / utilitaires / vues de la soi-disant "architecture de composant zope". Ceux qui vous permettent de faire une application robuste. Particulièrement pratique si vous devez plus tard le personnaliser sélectivement. Et la sécurité est traditionnellement un point fort de zope (et donc grok). Le développement et le déploiement sont entièrement gérés avec des œufs (et une construction): dans mon expérience, il s'agit d'une manière robuste et fiable et répétable et confortable.
Si vous avez une application pouvant fonctionner avec des tables SQL droites sans avoir besoin de personnaliser beaucoup plus sélectif, rien de mal avec Django. Vous devrez faire beaucoup de sécurité vous-même, de sorte que cela a besoin d'un œil enthousiaste. Il y a beaucoup moins d'un cadre derrière celui-ci (un orme et une URL mapper), de sorte que votre python se sentira plus "pur et simple". Cela signifie également que vous devez faire plus vous-même.
Il n'y a rien de vous empêcher de vous arrêter de manière sélective en utilisant des parties de grok: http: //pypi.python. Org / pypi / grokcore.component par exemple est beaucoup le noyau. Assez bien isolé, vous pouvez donc l'utiliser sans acheter dans toute la pile de Zope. Je suis sûr que vous pouvez utiliser cela à Django. Le composant Grokcore / Zope n'est que du code Python. Cela vous obtient les adaptateurs / interfaces / utilitaires. Je ne sais pas ce que vous construisez, vous devrez donc expérimenter.
Une chose extrêmement en faveur de Grok que je suggérerais d'essayer d'essayer: la base de données d'objets ZODB de Zope. Un bon orm (et Django est plutôt correct) aide beaucoup à sortir de la douleur des bases de données SQL, mais une véritable base de données d'objets est tout simplement luxueuse: -)
Zope était le premier cadre d'édition d'objet Evah, et la communauté Zope a une longue expérience de faire des choses de bonne manière. Zope 2 a été la première tentative, Zope 3 était la prochaine tentative et nous sommes maintenant dans la troisième génération de cadres Web, qui comprend Grok, BFG et Bobo.
Grok est massif et a encore plus de modules disponibles qui ne viennent pas lorsque vous installez la base (et il est en train de réduire également le nombre de modules requis, de sorte que l'empreinte est donc plus petite). BFG et Bobo vont dans l'autre sens et sont des cadres minimalistes mais avec un accès facile à la boîte à outils Zope et toutes les fonctionnalités de Zope.
Et bien que Django fait de nombreuses des mêmes erreurs Zope2, ils les fixent également beaucoup plus vite, alors je m'attends donc à ce que cette discussion soit discutée dans cinq ans, car je m'attends à ce que chaque site Web python utilise WSGI. + Webob + repoze + délivrance + bâtiment comme base d'ici là. Mais même alors j'irais pour des cadres où je peux utiliser l'architecture de composants Zope et ZODB, mais cela inclut non seulement ceux fabriqués par la communauté Zope, mais aussi par exemple des turbogears. Et peut-être que cela inclura aussi Django à ce moment-là, qui sait ...: -)
Selon les exigences du projet, je voudrais aujourd'hui avec soit Plone (s'ils ont besoin de CMS), Grok ou BFG (en fonction des développeurs concernés et de la complexité de la tâche et du budget). Ceci est bien sûr en partie en partie dépendant de ma grande expérience des technologies de Zope et de ma petite expérience avec Django, mais surtout parce que je peux utiliser ZTK et ZODB dans GROK et BFG.
ymmv, etc., blahablah.