Journal TurboGears, Django et Payflow

Posté par .
Tags : aucun
0
20
déc.
2006
Bonjour,

je cherche un framework de développement web en Python qui serais :

- moderne
- gère bien les BDD
- rapide à développer (Zope 3 trop laborieux pour mes deux seules mains)
- dont l'archi colle le moins possible au (X)HTML genre XUL (donc AJAX), SVG, PDF, RSS, etc.

J'ai donc passé quelques jours sur TurboGears et Django qui m'apparaissent le plus proche de ce que je cherche, mais je n'ai pas encore su les départager. Django est censé être plus poussé au niveau des objets BDD mais je n'ai pas franchement vu la portée de la chose. Et TurboGears plus poussé AJAX de part le fait qu'il inclue un kit par défaut. Sauriez-vous dont me faire part de votre expérience, et aborder d'autres points que je n'aurais pas envisagé (stabilité, clustering, migration, etc.).

Ensuite je cherche à pouvoir y intégrer un moyen de payement assez avancé (transaction immédiate, confirmation, validité, solvabilité, interrogation, etc.) genre Payflow de PayPal, mais si y'a autre chose je suis preneur, surtout si y'a des bindings Python bien rodés.

Voilà tout.

Merci.

Camille.
  • # Facile...

    Posté par . Évalué à -1.

    Django a un meilleur nom: http://fr.wikipedia.org/wiki/Django_Reinhardt

    De rien.
  • # Je ne serai quoi te conseiller ...

    Posté par (page perso) . Évalué à 7.

    Je m'interesse énormément au python/web

    Cependant, bien que j'ai testé les 2, vite fait ... J'ai du mal à accrocher à l'un ou à l'autre ... (j'aime pas les frameworks)
    L'approche MVC est certes interessante, mais j'ai du mal à m'adapter à un framework qui m'impose une certaine façon de faire (et il en est de même pour Ror, avant que qqu'un ne saute là dessus)
    Django est plus proche dans l'esprit MVC/ror, en proposant du tout frais. Turbogears est plus dans l'esprit réutilisation (à base de libs connus).
    Prônant la réutilisation j'aurai tendance à préconiser TG. Mais on entends plus de bien sur django.

    Maintenant aussi, je n'aime pas les frameworks qui impose des conventions, et t'oblige à apprendre les règles du framework ...
    Je préfère faire le mien, qui par définition, me va mieux ! (attention : ce n'est réinventé la roue non plus !!! car le web sous python c'est avec le standard WSGI, donc on peut réutiliser plein de choses existantes, et les agancer à sa guise (j'y reviens plus tard))

    Je suis un grand/big fan de webpy ( http://webpy.org/ ) (l'anti framework par excellence, mais qui apporte son lot de choses magiques). Avec lequel tu peux batir aisément ton propre framework, en utilisant les mêmes briques que TG par exemple.

    Dans le même style, en light, il y a collubrid ( http://wsgiarea.pocoo.org/colubrid/ )... ou des choses comme pylons ( http://pylonshq.com/ ) ou simpleweb ( http://simpleweb.essienitaessien.com/getstarted ) qui sont light aussi et apporte une approche MVC light également (en donnant moins de contraintes que django ou tg) (d'ailleurs avant de partir dans Django/TG, il est bien de matter simpleweb avant, car c'est vraiment le MVC au plus simple ! du coup ça permet de bien comprendre les 2 mastodontes)

    Dans la mesure où maintenant, le web en python est bati autour de WSGI (tous sont wsgi, evidemment).

    Sinon comme dit, il existe déjà des foultitudes de briques WSGI (http://wsgi.org/wsgi/Middleware_and_Utilities) , qui chainées entre elles, te permettent également d'arriver à des choses vraiment sympas très rapidement.

    Moi perso, webpy me suffit amplement pour la majorité de mes besoins (avec utilisations de briques externes suivant les besoins, mais webpy vient également avec le minimum syndical).

    Mais si devais partir sur un gros truc, je partirai maintenant avec des briques WSGI que je monterai moi même, avec paste ( http://pythonpaste.org/index.html )

    ça peut paraître un peu complexe par rapport aux soluces des frameworks clé-en-mains. Mais ça ne l'est absolument pas (http://wsgi.org/ et les docs sur paste expliquent vraiment bien les fondements et l'idée derrière tout ça).

    SInon, un truc pour un système de payement, faut bien partir du principe, qu'en python, il existe des libs pour tout ce qui est imaginable ... avec google, je suis tombé la dessus : http://sourceforge.net/projects/pypfpro/ ça devrait faire l'affaire !
    (cependant, en python, il existe souvent plusieurs libs, donc faudrait poursuivre les recherches, et trouver la mieux)
    • [^] # Re: Je ne serai quoi te conseiller ...

      Posté par . Évalué à 4.

      Maintenant aussi, je n'aime pas les frameworks qui impose des conventions, et t'oblige à apprendre les règles du framework ...


      s/les frameworks(.*)$/les frameworks./
      Concrêtement, tu n'aimes pas les frameworks tout court : un framework est justement là pour te fournir un cadre de développement, t'imposer une certaine rigueur, etc. Si ça ne te plait pas (ce qui est parfaitement honorable hein, pas de jugement de valeur attention), c'est que tout bêtement tu ne veux pas d'un framework de développement.
  • # idem..

    Posté par (page perso) . Évalué à 3.

    Je suis un peu dans ta situation et, à première vue, Django me semble plus clair, plus clean, plus intuitif, mieux documenté.

    Je cherche à être efficace et j'ai configuré ultra facilement django sur un serveur debian testing.

    Turbogears me semble plus foutoir, plus "ajax kikoo lol". C'est bête, mais c'est l'intuition que j'en ai.
  • # Django / Satchmo

    Posté par . Évalué à 3.

    Je ne vais pas argumenter sur Django / Turbogears : tu trouveras pleins d'articles trollant très bien sur le net et au final le mieux serait sans doute que tu essaies les deux suffisament longtemps pour faire ton choix.

    Par contre, tu pourrais être intéressé par le projet Satchmo [1], basé sur Django puisqu'il s'agit d'un projet de e-commerce. Si jamais tu te penches dessus, je ne saurais que trop te conseiller de t'abonner à la liste de diffusion.

    [1] http://www.satchmoproject.com
  • # Merci

    Posté par . Évalué à 1.

    Merci a tous pour ces suggestions, particulierement manatlan pour son post detaille :-) Re-au boulot !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.