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)
# Je ne serai quoi te conseiller ...
Posté par manatlan (site web personnel) . En réponse au journal TurboGears, Django et Payflow. Évalué à 7.
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)