Discussion :

[Luke spywoker]

Salut les WebPythons,
En faisant mes premiers pas avec le framework cherrypy j'ai remarquer que celui-çi, que j'ai choisi pour sa simplicité, avec son coté objet ne correspond pas a ce que désire monter comme site.
Alors je vous demande si il ne serai pas mieux que j'utilise le serveur CGI inclus dans la bibliothèque standart ou est-ce-que c'est du suicide au niveau stabilité du serveur.
Car je n'ai besoin que de quelques fonctionnalitées:
-Authentification (pour cela cherrypy convient)
-Génération de pages html (le coté objet de cherrypy ne convient pas du tout)
-Base de données interne (je sais pas)
Je vous demande votre avis sur la solution a employer, avant de vraiment me lancer.

Pour plus de clarté la question est:

Est-ce du suicide de développer un site web avec la bibliothèque standart de python 2.6 ?

Merci pour vos réponses.

[wiztricks]

Salut,

L'intérêt d'utiliser un framework tel que Cherrypy, django, pylons,... est de pouvoir se concentrer sur le développement du contenu sans avoir a refaire tout un boulot d'interfaces, d'organisation des modules, données.

Apprendre à utiliser un framework demande un temps plus ou moins long... mais ils disposent en général de bons tutos qui permettent de démarrer assez rapidement même si on n'a pas encore tout compris.

Après c'est vous qui voyez mais avec les bibliothèques de base ce sera: plus de code, plus de tests, plus de bugs... et des difficultés pour faire évoluer le site.

Mais je reconnais que l'état d'esprit d'un codeur s’accommode mal de l’apprentissage des recettes d'utilisation d'un framework ou on doit apprendre à se plier à des conventions en évitant de trop chercher à comprendre le pourquoi et le comment...

- W
PS: Personnellement, j'utilise Pylons (now Pyramid) qui sert de base à Turbogears. Cela me permet d'avoir une base "riche" pas trop obèse et la possibilité de pousser dans des environnements offrant des fonctionnalités "normales".

[Luke spywoker]

Merci pour l'encouragement,
Il est dit dans la doc que le framework se basait sur la méthode cgi.FieldStorage du module cgi pour par exemple uploader un fichier, je me suis dit que j'étais capable de l'implémenter moi meme mais je débute a peine et vous remercie de me faire part de votre expérience.
Je vais perséverer...
Par ailleur cgi est l'abbréviation de Common gateway Interface si je ne trompe pas et qu'il se base sur la transmission de paramètres dans l'URL et que c'est assez ancien comme technique et quelle est de bas niveau donc:

plus de code, plus de tests, plus de bugs... et des difficultés pour faire évoluer le site.

Disons que sa me tente mais j'ai peur que sa ne soit pas stable ayant fait de mauvaises expériences avec les socket en pythons.
Merci pour la réponse a ma question.

[wiztricks]

Salut,

Par ailleurs cgi est l'abbréviation de Common gateway Interface si je ne trompe pas et qu'il se base sur la transmission de paramètres dans l'URL et que c'est assez ancien comme technique et quelle est de bas niveau.

Le G de CGI est pour "Gateway".

C'est un "standard" permettant d'interfacer un serveur HTTP avec un environnement d'exécution de scripts tels que PHP ou Python ou Java.
Le script lancé par l'interface reçoit un ensemble de paramètres décrivant la requête et pas seulement l'URL.

Après bien sûr côté serveur HTTP, il faut lui dire quelles sont les requêtes qu'il devra "pousser" dans l'interface CGI et "en général" sa se passe au niveau des URL.

WSGI est une mouture "pythonique" (et plus moderne) de ce type d'interface qui permet d'empiler les services en cascade et d'avoir une sorte d'architecture "composants" lorsqu'on "généralise" son utilisation.
La plupart des framework Python proposent ce type d'interface et il existe à priori les DLL côté serveur HTTP genre NGINX, Apache,... permettant d'y intégrer une application construite suivant WSGI.

L'important est: "permettant d'y intégrer".
Vous développez l'application et le reste n'est que de la tuyauterie que vous configurez en fonction de la charge, de l'hébergement,...
- W