Fondamentalement, le manque de modularité et 'interopérabilité des composants des divers framework est ce dont se plaint GvR, et je trouve sa remarque très pertinente.
Il note que la plupart des composants ne sont pas (ou sont peut) interchangeables, à l'exceptions des seules parties reposant sur WSGI: pas d'API unifiée pour les framework d'auth, de templating, de persistance, de réécriture d'url etc. Par ailleur il note que les gros framework sont souvent documentés pour une utilisation "tout en un" (pas de tuto sur l'utilisation spécifique d'un composant précis).
La conséquence c'est qu'il faut choisir un environement complet ou rien, meme si, ce qui nous conviendrai le mieux serai par ex. une utilisation combinée du moteur de template de django, de l'ORM sqlobject, de l'interface avec le serveur web WSGI, Twisted pour les accès soap/rpc/webservices, Route pour la réécriture d'url, une combinaison ldap/coockie/sessions pour l'auth, mochikit pour ajax...
Ce manque de modularité / interopérabilité / documentation est d'autant plus dommage qu'aucun framework ne peut prétendre couvrir tout les besoins/priorités des developpeurs, et que tous sont pensés à partir d'idées/d'attentes pré-conçues. Cf. le commentaire de GvR sur RoR par ex., ou bien sur les moteurs de templates conçus pour génerer du xml/html mais pas du texte brut, sur les couches de persistances supposant un accès sql à l'exclusion d'une serialisation directement dans des fichiers (ou pire: qui imposent un schema préderminé de base, donc incomatible avec une base déjà existante) et surtout sur l'authentification/authorisation (à mon avis le pire problème, parce que la gestion des utilisateurs est vraiment une problèmatique au cas par cas selon l'entreprise, ldap, kerberos, sql, unix pwd, ... les possibilités sont nombreuses).
Je trouve d'autre part que ce débat à mis à jour une incroyable multiplicité de solutions (frameworks complets ou composants), entre lesquelles il devient très difficile de choisir (d'autant que le choix est généralement décisif, bloquant, et sans retour, vu le manque d'interopérabilité). Le fait que GvR pose sa question est la preuve qu'il y a un problème de lisibilité dans cet ensemble de framework (et le fouilli de réponse prouve combien il est difficile de s'y retrouver).
Il faudrait des mois pour évaluer ces différents framework (ou composants plus ou moins compatibles) web: turbogears, zope/plone, django, web.py, cheetah, myghty, stan, Kid, pylons, Paste, Nitro, cherrypy, rhubarbtart, route, karrigel, web.py, quixote, webware, skunkweb, subway, aquarium, webstack, nevow, ...
C'est énorme !
Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ? et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
GvR note aussi que l'utilisation des gros frameworks combinés est beaucoup plus longue et difficile qu'il n'y parrait (cf. son commentaire: RoR permet de coder vite .. uniquement si on maitrise déjà parfaitement ruby, le sql, le javascript, et tt les différents composants du framework, ou sa réponse a Lunh: tu t'en sort facilement avec django parceque tu es expert python, celementree etc.).
Est-ce qu'un bon jeux de petites libs, à l'API stable et bien documentée, sous tests unitaires indépendants, réutilisables, combinables entres elles à volontée et des tutos sur la façon de les combiner ne serait pas mieux que d'énormes usines à ga^W^W monuments comme zope ou django ? (c'est ce qu'on fait perl -avec cpan - et php avec pear, et non, pypy n'est pas du même ordre).
J'espère que GvR sera entendu lorsqu'il appelle à faire des PEP equivalents à WSGI sur les autres composants des frameworks web (l'auth, les templates etc).
[^] # Re: à propos de Django,
Posté par herodiade . En réponse au journal Guido juge le monde web Python. Évalué à 6.
Il note que la plupart des composants ne sont pas (ou sont peut) interchangeables, à l'exceptions des seules parties reposant sur WSGI: pas d'API unifiée pour les framework d'auth, de templating, de persistance, de réécriture d'url etc. Par ailleur il note que les gros framework sont souvent documentés pour une utilisation "tout en un" (pas de tuto sur l'utilisation spécifique d'un composant précis).
La conséquence c'est qu'il faut choisir un environement complet ou rien, meme si, ce qui nous conviendrai le mieux serai par ex. une utilisation combinée du moteur de template de django, de l'ORM sqlobject, de l'interface avec le serveur web WSGI, Twisted pour les accès soap/rpc/webservices, Route pour la réécriture d'url, une combinaison ldap/coockie/sessions pour l'auth, mochikit pour ajax...
Ce manque de modularité / interopérabilité / documentation est d'autant plus dommage qu'aucun framework ne peut prétendre couvrir tout les besoins/priorités des developpeurs, et que tous sont pensés à partir d'idées/d'attentes pré-conçues. Cf. le commentaire de GvR sur RoR par ex., ou bien sur les moteurs de templates conçus pour génerer du xml/html mais pas du texte brut, sur les couches de persistances supposant un accès sql à l'exclusion d'une serialisation directement dans des fichiers (ou pire: qui imposent un schema préderminé de base, donc incomatible avec une base déjà existante) et surtout sur l'authentification/authorisation (à mon avis le pire problème, parce que la gestion des utilisateurs est vraiment une problèmatique au cas par cas selon l'entreprise, ldap, kerberos, sql, unix pwd, ... les possibilités sont nombreuses).
Je trouve d'autre part que ce débat à mis à jour une incroyable multiplicité de solutions (frameworks complets ou composants), entre lesquelles il devient très difficile de choisir (d'autant que le choix est généralement décisif, bloquant, et sans retour, vu le manque d'interopérabilité). Le fait que GvR pose sa question est la preuve qu'il y a un problème de lisibilité dans cet ensemble de framework (et le fouilli de réponse prouve combien il est difficile de s'y retrouver).
Il faudrait des mois pour évaluer ces différents framework (ou composants plus ou moins compatibles) web: turbogears, zope/plone, django, web.py, cheetah, myghty, stan, Kid, pylons, Paste, Nitro, cherrypy, rhubarbtart, route, karrigel, web.py, quixote, webware, skunkweb, subway, aquarium, webstack, nevow, ...
C'est énorme !
Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ? et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
GvR note aussi que l'utilisation des gros frameworks combinés est beaucoup plus longue et difficile qu'il n'y parrait (cf. son commentaire: RoR permet de coder vite .. uniquement si on maitrise déjà parfaitement ruby, le sql, le javascript, et tt les différents composants du framework, ou sa réponse a Lunh: tu t'en sort facilement avec django parceque tu es expert python, celementree etc.).
Est-ce qu'un bon jeux de petites libs, à l'API stable et bien documentée, sous tests unitaires indépendants, réutilisables, combinables entres elles à volontée et des tutos sur la façon de les combiner ne serait pas mieux que d'énormes usines à ga^W^W monuments comme zope ou django ? (c'est ce qu'on fait perl -avec cpan - et php avec pear, et non, pypy n'est pas du même ordre).
J'espère que GvR sera entendu lorsqu'il appelle à faire des PEP equivalents à WSGI sur les autres composants des frameworks web (l'auth, les templates etc).