J'ai utilisé des turbogears 1 pour le prototypage de petits sites depuis deux ans et que cela devient un peu longtemps dans la dent. Toute suggestion sur l'appel entre la mise à niveau vers les turbogears 2 ou passer à quelque chose comme Django? Je suis déchiré entre la familiarité de la communauté TG qui sont assez réactives et une très bonne documentation vs la communauté beaucoup plus grande utilisant Django. Je suis assez tenté par les fonctionnalités CMS intégrées et le support Google Appengine.
Des conseils?
7 Réponses :
Je suis sûr que vous auriez lu de nombreuses comparaisons entre les turbogears et Django sur le Web.
Mais quant à votre tentation sur CMS et GAE, je peux vraiment penser que vous devez aller à Django Way. Vérifiez-les et décidez-vous.
J'utilise Django depuis un an et quand j'ai commencé, je n'avais aucune expérience de Python ou de Django et je l'ai trouvé très intuitif d'utiliser.
J'ai créé un certain nombre d'applications de moteurs Google App Appelat Hobylist à l'aide de Django avec le dernier étant un CMS pour mon site. Utiliser Django a signifié que j'ai pu coder beaucoup plus rapidement et avec beaucoup moins de bugs.
J'ai de l'expérience avec Django et TG1.1.
imo, turbogears Strong Point est-ce que c'est ORM: SQLalchemy. Je préfère les turbogears lorsque la base de données des choses est non triviale.
Orm de Django n'est tout simplement pas si flexible et puissant.
Cela étant dit, je préfère Django. Si le schéma de base de données est un bon ajustement avec Orm de Django, j'irais avec Django.
Dans mon expérience, il s'agit simplement de moins de tracas pour utiliser Django par rapport aux turbogears.
TG2 est construit sur des pylônes qui possède également une communauté assez grande. TG a été plus rapide que TG1 et comprend un moteur de mise en cache par méthode (pas seulement des pages Web). Je pense que c'est plus sympathique ajax que Django à la manière dont les pages peuvent être facilement publiées dans HTML ou JSON.
Mise à jour 2011: Après 3 ans de cadres ballons, je suis un utilisateur heureux de http://bottlepy.org/
ive obtenu seulement une question ... est l'application que vous développez dirigée vers la mise en réseau sociale ou logique commerciale personnalisée?
Je trouve personnellement Django est bon pour les réseaux sociaux et les pylônes / turbogears si vous êtes vraiment Voulez-vous la flexibilité et aucune limite ...
juste mon 2c
"Personnellement, je trouve que Django est bon pour les réseaux sociaux" inutiles de manière inutile. Non.
TG2 semble beaucoup compliqué et déroutant, même pour faire un peu simple comme une page de connexion avec des messages d'erreur multiple Comment prolonger la fonctionnalité de connexion Turbogears 2.1 Je pense que c'est à cause de l'intempérance dans la modularité ...
Django Orm utilise la mise en œuvre active des enregistrements - vous verrez cette implémentation dans la plupart des orateurs. Fondamentalement, ce que cela signifie, c'est que chaque ligne de la base de données est directement mappée sur un objet dans le code et inversement. Des cadres orm tels que Django ne nécessiteront pas de prédéfinir le schéma d'utiliser les propriétés du code. Vous venez de les utiliser, car le cadre peut «comprendre» la structure en examinant le schéma de base de données. En outre, vous pouvez simplement enregistrer l'enregistrement dans la base de données, car il est mappé sur une ligne spécifique de la table.
SQLalchemy utilise la mise en œuvre de la mappeuse de données - Lors de l'utilisation de ce type de mise en œuvre, il existe une séparation entre la structure de la base de données et la structure des objets (elles ne sont pas 1: 1 comme dans la mise en œuvre active de l'enregistrement). Dans la plupart des cas, vous devrez utiliser une autre couche de persistance pour continuer à interagir avec la base de données (par exemple, pour enregistrer l'objet). Donc, vous ne pouvez pas simplement appeler la méthode Enregistrer () que possible lors de l'utilisation de la mise en oeuvre d'enregistrement active (qui est un con) mais d'autre part, vous ne devez pas connaître la structure relationnelle complète de la base de données à fonctionner. , comme il n'y a pas de relation directe entre le code et la base de données.
Alors, lequel d'entre eux gagne cette bataille? Rien. Cela dépend de ce que vous essayez d'accomplir. C'est à ma croire que si votre demande est une application essentiellement une application CRUD (Créer, lire, mettre à jour, supprimer), sans règles complexes à appliquer sur les relations entre les différentes entités de données, vous devez utiliser la mise en œuvre de l'enregistrement actif (Django). Cela vous permettra de configurer facilement et rapidement un MVP pour votre produit, sans aucun tracas. Si vous avez beaucoup de "règles d'entreprise" et de restrictions dans vos applications, vous pourriez être meilleur avec le modèle de mapper de données, car il ne vous attache pas et ne vous oblige pas à penser strictement comme un enregistrement actif.