Pour ceux qui ne connaissent pas encore TurboGears (affectueusement surnommé TG), c'est un framework web en Python (encore un n-ième clone de RoR diront les rubyistes en levant les yeux au ciel).
TurboGears est basé sur le patron de conception MVC et le serveur d'application cherryPy, propose un ORM, un moteur de template et un framework JavaScript (MochiKit) facilitant le développement d'application "web 2.0". La principale particularité de TG est la réutilisation des briques existantes pour offrir un environnement de développement web à la fois cohérent et "pythonique". Il se caractérise donc par une architecture modulaire, la plupart des composants pouvant être remplacés par d'autres comme par exemple le moteur de templates (Genshi => Mako).
Le système de widgets de TG 1.0 a été extrait de celui-ci sous le nom de Toscawidgets pour permettre sa réutilisation dans d'autres frameworks tels que Pylons.
La distribution de composants ou d'applications se fait par des eggs python à la manière des gems de Ruby/RoR. TG est vacciné contre le syndrôme NIH !
À l'heure actuelle, il existe trois branches stables de TurboGears :
- La 1.0.x sortie en 2007 qui utilise par défaut comme ORM SQLObject, le moteur de template Kid. Une version de maintenance avec des correctifs sera proposée prochainement ;
- La 2.0 sortie fin mai 2009 qui est une réécriture de TG par-dessus un autre framework Web : Pylons (en lieu et place de CherryPy). Vu la proximité des projets TG et Pylons, ils fut un temps envisagé de fusionner les deux projets. Mais cela n'a pas abouti, faute de concilier l'aspect minimaliste ainsi que la volonté de maximiser les choix ouverts aux développeurs de Pylons avec le côté tout-en-un de TG.
On peut considérer TG comme une distribution de Pylons avec un jeu de composants standards. TG profite de la robustesse de l'implémentation WSGI de Pylons tout en minimisant la courbe d'apprentissage et améliorant la productivité des développeurs.
Bien que les développeurs aient essayé de maintenir la compatibilité des APIs entre TG 1.0 et TG 2.0, les deux frameworks ne sont pas compatibles.
L'ORM par défaut devient SQLAlchemy et le moteur de template Genshi.
Cette version 1.1 est compatible avec la branche 1.0 et utilise les mêmes briques par défaut que TG2 (SQLAlchemy, Genshi). C'est une version intermédiaire permettant de maintenir les applications existantes avec des bases plus saines.
Prochainement, une consultation sera ouverte pour décider de l'avenir de TG 1.x, éventuellement le passage à CherryPy3 pour TG 1.5
Aller plus loin
- Page d'accueil de TurboGears (8 clics)
- Annonce sur le blog d'un des développeurs de TG 1.1 (8 clics)
- Documentation de TG 1.1 (4 clics)
- Documentation de TG 2.0 (3 clics)
- Page d'accueil de Toscawidgets (3 clics)
# Plein de branches
Posté par Bruno Michel (site web personnel) . Évalué à 10.
[^] # Re: Plein de branches
Posté par CrEv (site web personnel) . Évalué à 4.
qu'il y ait une 1.1 pendant qu'une 2 se prépare semble normal
que la 2 soit sortie avant la 1.1 qui elle même reprend des briques de la 2 sachant que la 1.5 doit contenir encore d'autres briques dont certaines s'éloignent de la 2 (qui elle aura peut-être évoluée entre temps) ... c'est un peu tordu...
[^] # Re: Plein de branches
Posté par GeneralZod . Évalué à 3.
Néanmoins, le seul passage de CherryPy à Pylons casse la compatibilité et le rends le portage d'applications complexes plus délicat.
En gros, TG 1.1 est là pour les sites déjà en production et leur faciliter la transition (même choix par défaut que TG2).
Quant à la 1.5, c'est en discussion, doit-on passer à CherryPy3 ce qui casserait la compatibilité avec TG 1.0/1.1/2.0 ? Il y a déjà un fork qui le fait, doit-on encore plus faciliter la transition de TG 1.1 vers TG 2.0 ? notamment en supprimant les API dépréciés etc ...
[^] # Re: Plein de branches
Posté par Antoine . Évalué à 3.
(la présence de MochiKit comme bibliothèque Javascript est un bon avertissement :-))
En même temps, ça montre qu'ils n'abandonnent pas leurs utilisateurs, ce qui est plutôt chouette.
[^] # Re: Plein de branches
Posté par GeneralZod . Évalué à 3.
http://docs.turbogears.org/1.0/SitesUsingTurboGears
[^] # Re: Plein de branches
Posté par nomorepost . Évalué à 3.
CherryPy est pourtant un bon framework.
[^] # Re: Plein de branches
Posté par GeneralZod . Évalué à 4.
Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Deuxièment, TG est né de la volonté d'utiliser les meilleurs composants existants et d'en faire un framework web cohérent sans être monolithique et familier aux développeurs Python.
Un des objectifs de TG2 était le support de la norme WSGI[1] principalement pour une meilleure interopérabilité avec les autres projets. Certes CherryPy 3 convenait parfaitement, mais le choix de Pylons (Paste à l'époque), s'est fait à cause de l'affinité naturelle des 2 projets et des équipes[2] au point d'évoquer une fusion des projets[3].
Mark Ramm est un des développeurs principaux de TG.
[1] http://compoundthinking.com/blog/index.php/2009/02/04/wsgi-a(...)
[2] http://compoundthinking.com/blog/index.php/2007/07/09/turbog(...)
[3] http://compoundthinking.com/blog/index.php/2007/03/05/mergin(...)
[^] # Re: Plein de branches
Posté par nomorepost . Évalué à 6.
Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Cette remarque est valable aussi pour un passage à Pylons.
Pour le reste, il n'y a donc aucune raison objective à ce fork.
Je trouve ca dommage pour l'avenir de CherryPy car plus aucun framework haut niveau sérieux ne s'appuie dessus.
Par ailleurs, tu sembles indiquer que la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort puisqu'on se pose la question de l'intégration de CherryPy3 à la branche 1.x et non 2.x.
Ca casse un peu le mythe non ?
Dans ce cas, autant prendre un bon framework tout-en-un ala Django.
C'est une vraie question pas une tentative de troll.
[^] # Re: Plein de branches
Posté par Antoine . Évalué à 3.
Le jour où Django supportera correctement SQLAlchemy, peut-être ;)
[^] # Re: Plein de branches
Posté par GeneralZod . Évalué à 6.
Justement quitte à casser la compatibilité, autant explorer d'autre pistes. C'est vraiment la convergence de visions des deux équipes sur ce que doit être un framework web moderne qui a fait ce choix.
Quant à CherryPy3/TG1.5, une discussion est ouverte mais rien n'est décidé. Vu la tendance, c'est très peu probable (d'où un fork Gearshift). le projet a très clairement affirmé que TG2 constituait l'avenir, TG1 est destiné uniquement aux applications déjà en production.
> la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort
Mis à part le coeur de TG2 en l'occurence la partie contrôleur (ici Pylons), tout est interchangeable, les ACLS, l'authentification, le moteur de template, l'ORM, les widgets etc ...
sinon, ce serait plus un framework mais un bric à brac. :]
L'autre question que j'anticipe, c'est quel est l'intérêt par rapport à un Pylons brut de décoffrage ? Pylons offre trop de choix, Routes (le dispatcheur d'url) trop compliqué. TG2 t'offre un environnement par défaut utilisable hors-de-la-boite avec la possibilité d'utiliser tes composants préférés. D'ailleurs, TG2 a été très bien accueilli par la communauté Pylons parce que cela répondait aux besoins de certains développeurs.
Par rapport à Django, même si ça évolue, l'intérêt de TG c'est de minimiser la courbe d'apprentissage. Tu peux réutiliser la plupart des connaissances acquises dans d'autres projets.
Django est plus orienté CMS et gestion de contenu, ressemble plus aux autres frameworks web et conviendra plus aux développeurs web.
Alors que TG s'adresse plutôt à un public de développeurs Python chevronnés par son côté plus pythonnique, utilisation de constructions avancés (gestion des urls par des décorateurs comme CherryPy), WSGI (Mark Ramm de TG2 a créé une polémique à ce sujet lors du dernier DjangoCon) concept inexistant chez Django sensé favoriser l'interopérabilité entre les frameworks web python.
Voici le point de vue d'un développeur Django
http://www.biologeek.com/django,traduction,web-frameworks/co(...)
[^] # Re: Plein de branches
Posté par nomorepost . Évalué à 2.
C'est nettement plus alléchant que ton premier argument.
# Ciel, c’est mardi !
Posté par Sylvain Sauvage . Évalué à 8.
Non. D’abord, ils lèvent les yeux au ciel, car il n’y en a qu’un. Ensuite, dans cette acception, à la rigueur, on dit « les cieux », un collectif à usage emphatique.
« Ciels » n’est utilisé que lorsque l’on compte les ciels, p.ex lorsqu’il s’agit d’objets (ciels de lit (cf. œils-de-bœuf)), de peinture (les ciels de Millet = les différentes représentations du ciel par Millet) ou encore lorsqu’on les différencie (le septième des ciels, les ciels de printemps).
Sur ce →[]
[^] # Re: Ciel, c’est mardi !
Posté par patrick_g (site web personnel) . Évalué à 2.
# peut-on m'expliquer ...
Posté par Christophe Turbout . Évalué à 4.
je vois pas bien l'intérêt du dit framework s'il faut re-développer entre chaque version ...
n'étant pas pythoniste même s'il m'est déjà arrivé de jouer avec une fois (j'avais franchement pas été convaincu de la qualité des libs webservice à l'époque mais c'était il y a 3 ans), peut-on m'expliquer l'intérêt d'utiliser un tel framework ?
Je précise, ce n'est pas un troll, c'est une vraie question.
PS: quand j'ai lu la news, n'étant pas spécialiste du domaine j'ai vraiment cru à un business loto ... notamment sur lors de l'histoire des branches ...
# Sur quel type d'applis peut-on l'utiliser ?
Posté par norbs . Évalué à 2.
Par exemple sur un même serveur web attaquant la même bdd est-ce que les perfs seront comparables à ce qu'on peut avoir avec du php ? avec du jboss ? avec du coldfusion ? avec de l'asp (je sais c'est mal) ?
Est-ce que les connexions bdd sont gérées avec des pools de connexion comme c'est le cas avec des serveurs J2EE ?
[^] # Re: Sur quel type d'applis peut-on l'utiliser ?
Posté par GeneralZod . Évalué à 4.
Après d'autres facteurs rentrent en compte, l'architecture, les composants utilisés, mais également le temps de développement/maintenance.
Pour te donner un exemple, le moteur de template utilisé par défaut dans TG1.1/2.0 (et dans Trac) Genshi est environ 10 fois plus lent que Mako (défaut de Pylons) ou Jinja2. Or pour la plupart des applications, c'est secondaire. Le fait que les templates Genshi sont du xml directement affichable dans un navigateur web et par la même facilite la collaboration avec des graphistes est très appréciés.
Là où ça devient intéressant c'est que selon tes besoins, Pylons ou TG te permettent de sélectionner les composants les plus appropriés.
http://genshi.edgewall.org/wiki/GenshiPerformance
http://www.makotemplates.org/
http://chrismoos.com/2008/01/27/genshi-vs-mako/
> Est-ce que les connexions bdd sont gérées avec des pools de connexion comme c'est le cas avec des serveurs J2EE ?
Pour les connexions aux bases de données, l'ORM SQLAlchemy gère effectivement les pools de connexions (http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/pooli(...) Tu peux également taper directement dans la base de données avec l'api Python DB-API 2.0, même si la plupart des pilotes le gère (pyscopg2, mysqldb etc ...) le pooling n'est pas requis mais il y a des modules qui pallient à ce problème.
Voilà comment faire avec Pylons/TG2
http://wiki.pylonshq.com/display/pylonscookbook/Using+the+DB(...)
On ne l'a pas évoqué dans la discussion mais si tu as vraiment besoin de grosses performances, tu peux utiliser des frameworks plus petits comme werkzeug ou CherryPy.
C'est moins prémaché mais tu peux utiliser les mêmes composants (templates, ORM, authentifications). J'ai beaucoup aimé werkzeug qui est très simple et que j'explorerais un peu plus dès que j'aurais le temps. :o)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.