Journal Ode à cherrypy

Posté par  (site web personnel) .
Étiquettes : aucune
0
5
déc.
2004
Outre le fait que le python c'est vraiment bien ;-)

Il existe une foultitude de framework pour faire des développements web en python (zope, mod_python, quixote, karrigel ...)
En choisir un relève d'un parcours du combattant, tellement ils divergent dans leurs choix/solutions ...

Moi même, je voulais vite réaliser une petite appli web "pas en php", mais en python ... j'ai testé qqu'uns de ces frameworks ... et ai fini par retenir cherrypy (cp2 pour les intimes) ...

Quel bonheur ! (Moi qui suis obligé de développer ce genre de choses avec des technos comme dot.net, asp ou php ... ça me fait un bien fou !)
J'ai trouvé le framework quasi parfait pour réaliser des applis web ! Plus simple ; ce n'est pas possible ! ça n'existe pas !

Pour dire, c'est certainement la méthode la plus pythonique qu'il soit ! Faire une appli web, consiste à écrire du code python, tout simplement ! Sans autres artefacts ...

Les pages sont mappées sur des class/méthodes, et les paramètres web sont les paramètres des méthodes ... en gros ...
Le serveur web est intégré, et la gestion des headers/sessions/post/upload/authentification est dispo simplement !

Une gallerie d'albums de photos, 20 lignes de codes, serveur web compris ... du pure bonheur !

De plus, CP2, contrairement à sa première mouture, n'intègre plus un moteur de template ... celui ci peut vient en add-on ! Ou l'utilisateur peut en prendre un autre ...
Et il est toujours possible de coupler ça à un bon apache ...

Pour les fans de python, c'est à essayer ! Pour les fans d'applis web, c'est l'occasion de se mettre à python ...

Ce projet, cette technique, gagnerait à être connu ... ce pourquoi je me suis permis de venir ici en faire un peu de pub ...
http://www.cherrypy.org/(...)
  • # y a d'autres outils du style

    Posté par  (site web personnel) . Évalué à 2.

    dans .net tu as les web forms

    pour donner un exemple, prends un bon éditeur style visual studio .net (asp web matrix doit le faire mais bon).
    ensuite, tu places ce que tu veux sur la page, c'est du wysiwyg
    et là tu peux placer des évènements sur tout ce qui bouge, par exemple, tu peux mettre un évènement click sur le bouton et puis coder derrière côté serveur avec c#/vb.net.

    concrètement un développeur .net peut ne rien connaitre en html pour faire une appli sympa. (certes non optimisée mais bon)
    • [^] # Re: y a d'autres outils du style

      Posté par  . Évalué à 4.

      concrètement un développeur .net peut ne rien connaitre en html pour faire une appli sympa. (certes non optimisée mais bon)

      Ben moi ça me gène quand meme un peu... Je vois beaucoup de formations J2EE par exemple où on n'explique pas le HTML. Conclusion, les développeurs ne savent pas ce qu'ils font.... et font n'importe quoi des fois !

      Ce n'est pas qu'une question d'optimisation en plus. Moi ça me fait hurler quand je vois de très bons dévs J2EE ou .NET qui savent pas vraiment faire de HTML. Ca donne parfois des trucs horribles !!!
    • [^] # Re: y a d'autres outils du style

      Posté par  (site web personnel) . Évalué à 5.

      ça sent le troll caché ça ...

      C'est justement ce que je mange chaque jour ... les webforms
      Et c'est vraiment la techno ".net" qui m'embête le plus dans le framework !
      Je HAIS les "evenements serveurs" ! Et je pourrai en parler des heures !

      Et je peux te certifier que ça ne te fait pas gagner du temps ! ça te met une couche obscure qui te provoquera d'autres problèmes "non net", qui fait que tu passeras du temps à comprendre des choses (les entrailles microsoft) qui ne t'apporteront rien, qui n'ont rien à voir avec le dev web !!

      C'est pratique, pour faire la saisie d'une authentification par exemple ! Mais dès que tu veux faire qqchose de plus complexe, il faut vraiment s'accrocher, et plonger au coeur du système !

      C'est vraiment la techno microsoft, qui n'a pas d'avenir ! Autant dot.net s'en sortira, autant les webforms vont disparaître comme elles sont venues ...

      ça ne vaut, de loin pas, à mon humble avis, l'utilisation d'un moteur de template apportant une couche "forms" (smarty, quixote, ...)

      et je passe tous les problèmes inhérents à iis/vs ...

      Je pense que pour une même appli web, tu mettras 10x moins de temps à faire en cherrypy/python qu'en webforms/c#
      • [^] # Re: y a d'autres outils du style

        Posté par  (site web personnel) . Évalué à 5.

        je trouve ton avis très intéressant.
        Il est vrai que l'asp .net remplace la compréhension du html par la compréhension des web forms.

        après je ne pense pas que ce soit une techno morte, tu remarqueras que java courre aussi vers ce genre de techno (en plus verbeux) avec jsf. reste plus qu'à placer un éditeur wysiwyg et le compte est bon.

        l'intérêt des web forms amha sont les outils fournis fournis avec, comme le datagrid par exemple qui permettent de faire un très bon rendu et impec fonctionnellement (pour ceux qui connaissent pas, ca permet d'envoyer une requête ou plus largement des données, ca le met dans un tableau html puis on a accès à des fonctionnalités très facilement du style formatage des données, tri, ou encore le framework évènementiel ce qui permet de passer une seule ligne en mode édition etc.).

        sinon un truc sympa c'est qu'ils incitent fortement le développeur débutant à séparer le code et le design, ce qui n'est pas le cas lorsque l'on commence en jsp ou php.

        les web forms ne sont pas exempts de défauts malheureusement, faire un affichage équivalent mozilla / ie peut se rendre ardu.
        en plus il ne gère pas les templates (l'équivalent des tiles en struts), ca va être réglé en asp .net 2.0 mais bon pour l'instant ca manque terriblement.
  • # Webware

    Posté par  . Évalué à 1.

    Dans ce framework, les pages sont aussi mappées sur des class/méthodes. Il y a ce qu'il faut pour gérer les sessions & co et dispose de quelques modules interessants que l'on est libre d'utiliser ou non (dont un pour utiliser les PSP).
    Il peut être utilisé en cgi, en module apache voire en serveur web lui même.

    A première vue pas de grandes différences avec cherrypy mais je n'ai pas regardé en détail, je le ferai à l'occasion.

    http://www.webwareforpython.org/(...)
  • # autoreload

    Posté par  . Évalué à 1.

    En parcourant le wiki de cherrypy, je suis tombé sur une petite merveille : autoreload.py http://trac.cherrypy.org/cgi-bin/trac.cgi/wiki/AutoReload(...)

    C'est un petit script qui permet de recharger les modules automatiquement, sans arrêter le programme(serveur).
  • # Pareil mais en mieux

    Posté par  . Évalué à 2.

    Moi j'ai trouvé mon bonheur avec ikaaro : http://www.ikaaro.org/(...)

    Les avantages de Zope sans les inconvénients : pas de développement TTW, pas d'acquisition, pas besoin d'utiliser l'API heu... historique de Zope.
    Ça se programme entièrement depuis un produit Zope donc pas de paramétrage dans la ZMI et ultra simple à déployer, accès à toute la puissance de Zope. Ça s'appuye sur un module Python pour l'essentiel : itools.

    Ce dernier apporte un moteur de localisation et extraction des messages pour traduction (fichiers po), un de workflow (le seul en pur Python je crois), la stricte séparation données/présentation/logique, le moteur de templates Python le plus rapide, Tout ça s'appuye sur XML et la notion de handlers qui donnent leur sens aux données (notion de format de fichier et logique). On retrouve même la notion de programmation par aspects.

    Ikaaro est en fait, en gros, une adaptation d'itools à Zope : persistance et transaction des données avec la base de données objet ZODB et un publisher d'objets (mapping URL/objets/méthodes et leurs paramètres en gros). Ils se sont débarrassés des pires aspects de Zope et offrent une API super simple et puissante à la place. Et j'en oublie encore sûrement !

    Cherry semble avoir repris les bonnes idées de Zope mais ce dernier apporte quand même un grand plus pour des projets d'entreprise, ne serait-ce que les transactions ou la montée en charge.

    Enfin bref, je pourrais en parler pendant des heures moi aussi ! :-)

Suivre le flux des commentaires

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