à propos de Django,

• [^]Re: à propos de Django,

  Posté par Thomas Hervé () le 01/02/2006 à 10:59. (lien). Évalué à 3.

  Différents choses me génent. D'abord le moteur de templates ne me convient pas (l'exemple du sujet vient de là). C'est quand même un facteur important. De même leur ORM n'a rien d'extraordinaire (euphémisme).
  
  On vient donc au problème de fond: ils ne considérent pas l'existant. En gros ils refont tout eux-mêmes (voir ici : http://blogs.nuxeo.com/sections/blogs/fermigier/2006_01_22_u(...) ), sans regarder ce qui existe, et ne font pas vraiment mieux (ce n'est que mon avis). Du coup quand tu commences un projet avec Django tu utilises tout leurs outils, et tu ne peux pas vraiment en sortir ou choisir une solution qui te convient mieux pour un élément spécifique. De ce côté TurboGears est beaucoup intéressant (même si il ne manque pas de défaut).
  
  Enfin le problème de fond est qu'il n'y a pas de solutions émergeantes qui aie tout les avantages. C'est pourquoi Django séduit je pense: ca marche, tout simplement.

  • [^]Re: à propos de Django,

    Posté par herodiade () le 01/02/2006 à 14:37. (lien). Évalué à 6.

    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 Thomas Hervé () le 01/02/2006 à 15:13. (lien). Évalué à 3.

      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...
      
      Cela imposerait une standardisation à l'extrême. Aujourd'hui comme standards on a en gros WSGI et DBAPI. Le reste est encore flou, mais ce n'est pas vraiment spécifique à Python. Cela demandera un travail dingue de penser une interface d'authentification unique, qui répondent à la multiplicité de l'essence.
      
      Pourquoi autant de developpeurs python écrivent (et publient !) leur propre framework web ?
      
      C'est à mon avis lié à la population qui compose la communauté Python. De bons codeurs, pros du NIH, et qui n'ont pas de solution évidente à disposition. En comparaison, si je devais faire une appli en Java il y aurait 80% de chances que j'utilise Struts, parce c'est le choix le plus répandu et que mes connaissance de Java sont trop limitées pour que je réfléchisse plus loin.
      
      Au final si il y a autant de frameworks, c'est qu'il est très facile d'en faire un avec Python. On ne peut pas vraiment dire que ce soit un défaut du langage !
      
      et, par contraste, pourquoi si peu de travail et documentation sur l'intéropérabilité / l'unification ?
      
      Parce que comme dans toute communauté il est plus facile de coder que de documenter :).
      
      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
      
      Un bon nombre des composants que tu cites sont indépendants et des briques unitaires : kid, sqlobject, stan, mochikit, route, paste, cheetah, voire cherrypy. Et ces briques progressent beaucoup à l'heure actuelle, c'est d'ailleurs la raison qui me fait douter de Django et plus croire en TurboGears.