Je serais intéressé par tout retour d'expérience sur l'utilisation de
Cherrypy (et/ou similaires).
Si quelqu'un a un avis, et n'a pas son clavier en panne.... Merci d'avance.
Je suis de ton avis. Kid me semble trop orienté dans une direction qui n'est pas forcément celle de tout le monde. Quand à SQLobject, je me demande si c'est si intéressant d'ajouter une couche à un DB-API2 déjà très facile à utiliser (AMHA, cette remarque vaut aussi pour SQLalchemy).
Mais, en l'occurrence, j'avais lu que Franssoa utilisait deux des composants...
@+
MCI
Salut !
Je suis de ton avis.
Kid me semble trop orienté dans une direction qui n'est pas forcément celle
de tout le monde.
Quand à SQLobject, je me demande si c'est si intéressant d'ajouter une
couche à un DB-API2 déjà très facile à utiliser (AMHA, cette remarque vaut
aussi pour SQLalchemy).
Mais, en l'occurrence, j'avais lu que Franssoa utilisait deux des
composants...
Je suis de ton avis. Kid me semble trop orienté dans une direction qui n'est pas forcément celle de tout le monde. Quand à SQLobject, je me demande si c'est si intéressant d'ajouter une couche à un DB-API2 déjà très facile à utiliser (AMHA, cette remarque vaut aussi pour SQLalchemy).
Mais, en l'occurrence, j'avais lu que Franssoa utilisait deux des composants...
@+
MCI
Boris Borcic
William Dode wrote:
propre framework (cadre de travail ?). Je préfère ça parce que ca dre et travail, c'est deux mots que je n'aime pas trop ;-)
amha, "cadre de travail" correspondrait plutôt à workframe que framew ork, bon bref.
William Dode wrote:
propre framework (cadre de travail ?). Je préfère ça parce que ca dre et
travail, c'est deux mots que je n'aime pas trop ;-)
amha, "cadre de travail" correspondrait plutôt à workframe que framew ork,
bon bref.
propre framework (cadre de travail ?). Je préfère ça parce que ca dre et travail, c'est deux mots que je n'aime pas trop ;-)
amha, "cadre de travail" correspondrait plutôt à workframe que framew ork, bon bref.
sh
Bonjour tout le monde,
Désolé de remonter ce message mais je viens juste de tomber dessus.
Mais aujourd'hui, je suis plutôt entrain de lorgner du côté de wsgi. Maintenant on trouve toutes les briques qu'il faut pour se monter son propre framework (cadre de travail ?). Je préfère ça parce que cadr e et travail, c'est deux mots que je n'aime pas trop ;-)
WSGI est une interface. Ce n'est pas une librairie. Je dis cela car votre message laisse penser que c'est le cas. Comme vous dites WSGI offre une interface afin de coller plusieurs briques de sources différentes ensemble et c'est à peu près tout.
CherryPy possède une mise en oeuvre de WSGI tout comme d'autres librairies ou frameworks (Pylons, mod_python, Django, etc.).
Il est interressant de noter ceci dit que le module wsgiref mise en oeuvre par Phillip J. Eby, l'auteur de la PEP 333, sera inclu comme référence WSGI dans la stdlib.
Au cas où ça ne serait pas passé : http://wsgi.org
Le site que vous mentionnez n'est qu'un simple portail regroupant des informations sur WSGI.
Voilà je voulais juste préciser c'est tout :)
- Sylvain
Bonjour tout le monde,
Désolé de remonter ce message mais je viens juste de tomber dessus.
Mais aujourd'hui, je suis plutôt entrain de lorgner du côté de wsgi.
Maintenant on trouve toutes les briques qu'il faut pour se monter son
propre framework (cadre de travail ?). Je préfère ça parce que cadr e et
travail, c'est deux mots que je n'aime pas trop ;-)
WSGI est une interface. Ce n'est pas une librairie. Je dis cela car
votre message laisse penser que c'est le cas. Comme vous dites WSGI
offre une interface afin de coller plusieurs briques de sources
différentes ensemble et c'est à peu près tout.
CherryPy possède une mise en oeuvre de WSGI tout comme d'autres
librairies ou frameworks (Pylons, mod_python, Django, etc.).
Il est interressant de noter ceci dit que le module wsgiref mise en
oeuvre par Phillip J. Eby, l'auteur de la PEP 333, sera inclu comme
référence WSGI dans la stdlib.
Au cas où ça ne serait pas passé : http://wsgi.org
Le site que vous mentionnez n'est qu'un simple portail regroupant des
informations sur WSGI.
Désolé de remonter ce message mais je viens juste de tomber dessus.
Mais aujourd'hui, je suis plutôt entrain de lorgner du côté de wsgi. Maintenant on trouve toutes les briques qu'il faut pour se monter son propre framework (cadre de travail ?). Je préfère ça parce que cadr e et travail, c'est deux mots que je n'aime pas trop ;-)
WSGI est une interface. Ce n'est pas une librairie. Je dis cela car votre message laisse penser que c'est le cas. Comme vous dites WSGI offre une interface afin de coller plusieurs briques de sources différentes ensemble et c'est à peu près tout.
CherryPy possède une mise en oeuvre de WSGI tout comme d'autres librairies ou frameworks (Pylons, mod_python, Django, etc.).
Il est interressant de noter ceci dit que le module wsgiref mise en oeuvre par Phillip J. Eby, l'auteur de la PEP 333, sera inclu comme référence WSGI dans la stdlib.
Au cas où ça ne serait pas passé : http://wsgi.org
Le site que vous mentionnez n'est qu'un simple portail regroupant des informations sur WSGI.