Django vs autres Python frameworks web?
J'ai à peu près essayé tous les Python web qui existent, et il m'a fallu beaucoup de temps pour réaliser qu'il n'y avait pas de framework miracle, chacun avait ses propres avantages et inconvénients. J'ai commencé avec Snakelets et j'ai apprécié de pouvoir contrôler presque tout à un niveau inférieur sans trop de bruit, mais j'ai découvert TurboGears et je l'ai utilisé (1.x) Depuis lors, des outils comme Catwalk et la console Web sont inestimables pour moi.
Mais avec TurboGears 2 qui apporte le support de WSGI, et après avoir lu les débats religieux entre les Django et les camps WSGI, je suis vraiment déchiré entre "le faire de la bonne façon", par exemple, apprendre WSGI, passer du temps précieux à écrire des fonctionnalités qui existent déjà dans Django et d'autres frameworks full-stack, au lieu d'utiliser Django ou un framework de haut niveau qui fait tout pour moi. Les inconvénients de ce dernier que je peux voir sont assez évidents:
- Je n'apprends rien dans le processus
- Si jamais je dois faire quelque chose de plus bas, ça va être une douleur
- La surcharge requise pour un site de base qui utilise l'authentification est insensée. (OMI)
Donc, je suppose que ma question est, qui est le meilleur choix, ou est-ce juste une question d'opinion, et devrais-je le sucer et utiliser Django s'il atteint ce que je veux avec un minimum d'agitation (Je veux une authentification et une interface CRUD pour ma base de données)? J'ai essayé Werkzeug, Glashammer et mes amis, mais AuthKit et Repoze m'ont fait peur, ainsi que le nombre d'étapes nécessaires pour configurer l'authentification de base. J'ai regardé Pylônes, mais la documentation semble manquer, et lors du référencement de fonctionnalités simples comme l'authentification ou une interface CRUD, diverses pages wiki et documentation semblaient se contredire, avec différents hacks pour les versions et autres.
Merci à S. Lott d'avoir souligné que je n'étais pas assez clair. Ma question est la suivante: lequel des éléments suivants vaut la peine à long terme, mais n'est pas douloureux à court terme (par exemple, une sorte de terrain d'entente, n'importe qui?) Dans ce dernier cas, j'apprécierais une suggestion pour savoir si je devrais essayer Django un autre essai, m'en tenir à TurboGears 1.x, ou m'aventurer dans un autre cadre.
De plus, j'ai essayé CherryPy, mais je n'arrivais pas à trouver une application CRUD suffisamment bonne que je pourrais utiliser et utiliser immédiatement.
Je suggère de revoir TG2. Je pense que les gens n'ont pas remarqué certains progrès accomplis depuis la dernière version. Mis à part la pile croissante d'utilitaires WSGI disponibles, il existe un certain nombre d'éléments spécifiques à TG2 à prendre en compte. Voici quelques faits saillants:
TurboGears Administration System - Cette interface CRUD à votre base de données est entièrement personnalisable à l'aide d'une classe de configuration déclarative. Il est également intégré à Dojo pour vous offrir des tableaux à défilement infini. La validation côté serveur est également automatisée. L'interface d'administration utilise des URL RESTful et des verbes HTTP, ce qui signifie qu'il serait facile de se connecter par programmation en utilisant les normes de l'industrie.
CrudRestController / RestController - TurboGears fournit un moyen structuré de gérer les services dans votre contrôleur. Vous offrant la possibilité d'utiliser des verbes HTTP standardisés simplement en étendant notre RestController. Combinez Sprox avec CrudRestController, et vous pouvez mettre crud n'importe où dans votre application avec des formulaires générés automatiquement entièrement personnalisables. TurboGears prend désormais en charge les types MIME en tant qu'extensions de fichier dans l'URL, vous pouvez donc faire en sorte que votre contrôleur affiche .json et .xml avec la même interface qu'il utilise pour rendre html (renvoyant un dictionnaire à partir d'un contrôleur)
Si vous cliquez sur les liens, vous verrez que nous avons un nouvel ensemble de documentation construit avec sphinx qui est plus étendu que les documents du passé.
Avec le meilleur serveur Web , ORM , et système de modèles (s) (choisissez le vôtre) sous le capot, il est facile de comprendre pourquoi TG a du sens pour les personnes qui veulent se lancer rapidement et qui ont toujours une évolutivité à mesure que leur site se développe.
TurboGears est souvent considéré comme essayant d'atteindre une cible mobile, mais nous sommes cohérents en ce qui concerne les versions, ce qui signifie que vous n'aurez pas à vous soucier de travailler sur le coffre pour obtenir les dernières fonctionnalités dont vous avez besoin. À venir: plus d'extensions TurboGears qui permettront à votre application de développer ses fonctionnalités avec la facilité des commandes de paster.
les débats religieux entre les Django et les camps WSGI
Il semblerait que vous soyez un peu confus à propos de ce qu'est WSGI et de ce que Django est. Dire que Django et WSGI sont en compétition est un peu comme disant que C et SQL sont en concurrence: vous comparez des pommes et des oranges.
Django est un framework, WSGI est un protocole (qui est supporté par Django) pour la façon dont le serveur interagit avec le framework. Plus important encore, apprendre à utiliser directement WSGI est un peu comme apprendre Assembly. C'est une excellente expérience d'apprentissage, mais ce n'est pas vraiment quelque chose que vous devriez faire pour le code de production (ni prévu).
En tout cas, mon conseil est de le découvrir par vous-même. La plupart des frameworks proposent un exercice de type "créer un wiki/blog/sondage en une heure". Passez un peu de temps avec chacun et déterminez lequel vous préférez. Après tout, comment pouvez-vous choisir entre différents cadres si vous n'êtes pas prêt à les essayer?
Je dirais que vous êtes un peu trop pessimiste à propos de "ne rien apprendre" en utilisant Django ou un framework similaire à pile complète, et en sous-estimant la valeur de la documentation et d'une grande communauté. Même avec Django il y a encore une courbe d'apprentissage considérable; et s'il ne fait pas tout ce que vous voulez, ce n'est pas comme si le code du framework est impénétrable.
Une certaine expérience personnelle: j'ai passé des années, de temps en temps, à jouer avec Twisted/Nevow, TurboGears et quelques autres cadres Web Python. Je n'ai jamais rien fini parce que le code du cadre était perpétuellement inachevé et en cours réécrite sous moi, la documentation était souvent inexistante ou erronée et le seul support viable était via IRC (où j'ai souvent reçu d'excellents conseils, mais j'avais l'impression d'être imposant si je posais trop de questions).
En comparaison, au cours des deux dernières années, j'ai supprimé quelques sites avec Django. Contrairement à mon expérience précédente, ils sont en fait déployés et en cours d'exécution. Le processus de développement Django peut être lent et prudent, mais il en résulte beaucoup moins de bitrot et de dépréciation, et une documentation réellement utile.
Prise en charge de l'authentification HTTP pour Django enfin entré il y a quelques semaines, si c'est ce à quoi vous faites référence dans # 3.
Votre question semble être "vaut-il la peine d'apprendre WSGI et de tout faire vous-même" ou d'utiliser un "framework de pile complet qui fait tout pour vous".
Je dirais que c'est une fausse dichotomie et qu'il y a une troisième voie évidente. TurboGears 2 essaie de fournir un chemin fluide depuis un cadre de style "tout faire pour vous" jusqu'à une compréhension du middleware WSGI et une possibilité de personnaliser presque tous les aspects du cadre pour répondre aux besoins de votre application.
Nous ne réussissons peut-être pas à tous les niveaux et à tous les niveaux, mais surtout si vous avez déjà une certaine expérience de TurboGears 1, je pense que la courbe d'apprentissage TG2 sera très, très facile au début et vous aurez la possibilité d'aller plus loin exactement quand vous en avez besoin.
Pour résoudre vos problèmes particuliers:
- Nous fournissons un système d'autorisation prêt à l'emploi qui correspond à celui auquel vous êtes habitué de TG1.
- Nous fournissons une interface prête à l'emploi "Django admin" appelée tgext.admin, qui fonctionne très bien avec dojo pour faire une feuille de calcul sophistiquée comme interface par défaut.
J'aimerais également aborder quelques-unes des autres options qui existent et parler un peu des avantages.
CherryPy. Je pense que CherryPy est un excellent serveur Web et un joli cadre Web minimaliste. Il n'est pas basé sur WSGI en interne mais a une bonne prise en charge de WSGI bien qu'il ne vous fournira pas l'expérience de "pile complète". Mais pour les configurations personnalisées qui doivent être à la fois rapides et ne sont pas particulièrement adaptées aux valeurs par défaut fournies par Django ou TurboGears, c'est une excellente solution.
Django. Je pense que Django est un système très agréable et parfaitement intégré pour développer des sites Web. Si votre application et votre style de travail correspondent bien à sa configuration standard, cela peut être fantastique. Si toutefois vous avez besoin d'ajuster votre utilisation de la base de données, de remplacer le langage de modèle, d'utiliser un modèle d'autorisation utilisateur différent ou de faire les choses différemment, vous pourriez très bien vous retrouver à combattre le framework.
Pylônes Les pylônes comme CherryPy sont un excellent framework web minimaliste. Contrairement à CherryPy, WSGI est activé sur tout le système et fournit des valeurs par défaut sensées comme SQLAlchemy et Mako qui peuvent vous aider à bien évoluer. Les nouveaux documents officiels sont de bien meilleure qualité que les anciens documents wiki qui sont ce que vous semblez avoir regardé.
Avez-vous jeté un œil à CherryPy. Il est minimaliste, mais efficace et simple. Il est suffisamment bas pour ne pas les gêner, mais suffisamment élevé pour cacher la complexité. Si je me souviens bien, TurboGears a été construit dessus.
Avec CherryPy, vous avez tout le choix. (Framework de modèle, ORM si souhaité, back-end, etc.)
Apprenez WSGI
WSGI est absurdement simple .. C'est fondamentalement une fonction qui ressemble à ..
def application(environ, start_response) pass
La fonction est appelée lorsqu'une requête HTTP est reçue. environ contient diverses données (comme l'URI de la demande, etc.), start_response est une fonction appelable, utilisée pour définir les en-têtes.
La valeur retournée est le corps du site Web.
application def (environ, start_response): start_response ("200 OK", []) return "..."
C'est tout ce qu'il y a, vraiment .. Ce n'est pas un framework, mais plutôt un protocole à utiliser pour les web-frameworks ..
Pour créer des sites, utiliser WSGI n'est pas pas la "bonne façon" - utiliser les frameworks existants est .. mais, si vous écrivez un Python web-framework alors utiliser WSGI est absolument la bonne façon ..
Le framework que vous utilisez (CherryPy, Django, TurboGears, etc.) est fondamentalement une préférence personnelle. Jouez dans chacun, voyez ce que vous aimez le plus, puis utilisez-le. "Recommandation pour des cadres simples python frameworks"
Je dirais que la bonne réponse dépend de ce que vous voulez et de ce dont vous avez réellement besoin, car ce qui vaudra à long terme dépendra de ce dont vous aurez besoin à long terme. Si votre objectif est de faire déployer les applications dès que possible, alors l'itinéraire "le plus simple", c'est-à-dire. Django, c'est sûrement la voie à suivre. La valeur d'un système bien testé et bien documenté qui exactement ce que vous voulez ne peut pas être sous-estimé.
D'un autre côté, si vous avez le temps d'apprendre une variété de nouvelles choses qui peuvent s'appliquer dans d'autres domaines et que vous souhaitez avoir la plus grande marge de personnalisation, quelque chose comme Turbogears est supérieur. Turbogears vous offre une flexibilité maximale, mais vous allez devez passer beaucoup de temps à lire des documents externes pour des choses comme Repoze, SQLAlchemy et Genshi pour obtenir quelque chose d'utile. Les documents TG2 sont délibérément moins détaillés que les documents TG1 dans certains cas, car il est considéré que les documents externes sont meilleurs qu'avant. Que ce genre de chose soit un obstacle ou un investissement dépend de vos propres besoins.
Avez-vous vérifié web2py? Après avoir récemment évalué de nombreux frameworks Web Python récemment, j'ai décidé d'adopter celui-ci. Consultez également Google App Engine si vous ne l'avez pas déjà fait.
Django vaut vraiment la peine d'être appris, et sonne comme il conviendra à vos besoins. L'interface d'administration fournie est facile à installer et à utiliser, et elle utilise l'authentification.
Quant à "n'importe quel niveau inférieur", si vous voulez dire sql, il est tout à fait possible d'insérer sql dans vos requêtes avec le mot-clé supplémentaire. Stylistiquement, vous essayez toujours d'éviter cela autant que possible.
Quant à "ne rien apprendre" ... la vraie question est de savoir si vous préférez apprendre quelque chose de niveau inférieur ou supérieur, ce qui n'est guère une question à laquelle tout le monde ici peut répondre pour vous.
Les pylônes me semblent un excellent outil:
- un vrai framework web (CherryPy n'est qu'un serveur web),
- petite base de code - réutilisation d'autres projets,
- écrit entièrement avec WSGI à l'esprit, basé sur Paste,
- vous permet de coder l'application immédiatement et de toucher les bits de bas niveau si nécessaire,
J'ai utilisé CherryPy et TurboGears et j'ai regardé de nombreux autres frameworks mais aucun n'était aussi léger et productif que Pylons. Vérifiez le présentation sur Google .
Je suggérerais pour TurboGears 2. Ils ont fait un travail fantastique d'intégrer le meilleur du monde Python.
WSGI: En supposant que vous développez des projets/solutions commerciales modérément complexes dans TG2 ou dans un autre cadre, dites Grok. Même si ces cadres prennent en charge WSGI, cela signifie-t-il que celui qui utilise ces cadres doit apprendre WSGI? Dans la plupart des cas, la réponse est non. Je veux dire qu'il est bon d'avoir cette connaissance sans aucun doute.
La connaissance WSGI est probablement plus utile dans des cas comme
- vous souhaitez utiliser un middleware ou un autre composant qui n'est pas fourni dans le cadre de la pile standard, par exemple. Authkit avec TG ou Grok sans ZODB .
- vous faites une intégration.
CherryPy est bon mais pensez à gérer vos validations/rollbacks de base de données à la fin des transactions, exposant json, validations dans de tels cas TG, Django comme les frameworks font tout pour vous.
Je suis un fan de TurboGears, et c'est exactement la raison pour laquelle: un très bon compromis entre le contrôle et faire les choses correctement vs facile.
Vous devrez bien sûr vous décider. Vous préférez peut-être en apprendre moins, peut-être plus. Peut-être les domaines que j'aime la connaissance/le contrôle (base de données par exemple), vous ne vous en souciez pas. Et ne vous méprenez pas. Je ne caractérise aucun cadre comme nécessairement difficile ou incorrect. C'est juste mon jugement subjectif.
Je recommanderais également TurboGears 2 si possible. Quand il sortira, je pense que ce sera bien mieux que 1.0 en termes de ce qu'il a sélectionné pour les valeurs par défaut (genshi, pylônes, SqlAlchemy)