Journal Choisir un framework web...

Posté par .
6
22
jan.
2010
Salut,

Je me renseigne actuellement sur les différents frameworks web qui me permettraient de développer un site web simplement et rapidement.

Afin de découvrir autre chose, je regarde vers d'autres langages que PHP.

D'après ce que j'ai pu voir il y à principalement 2 frameworks assez populaires, j'ai nommé Django et RoR. Il semblerait que RoR soit plutôt orienté application web tandis que Django soit orienté publication... Mais que désigne ces termes cela veut-il dire que Django ne peut pas faire ce dont est capable RoR ? J'en doute un peu...

Quoi qu'il en soit, j'ai aussi repéré Pylons, TurboGears ou encore Merb mais j'avoue ne pas savoir lequel prendre.

Je vais donc les essayer mais j'aimerais aussi avoir vos opinions. Lequel utilisez-vous et pourquoi ?

Je cherche à faire un petit site qui se chargera principalement de la gestion de fichiers audios, de l'écriture et de l'affichage de leurs tags avec quelques news.

Et regardant sur les exemples que l'on peut trouver le site de chaque framework, pour l'instant j'aime bien RoR qui me paraît assez clair dans son fonctionnement et dans la syntaxe Ruby.

Je ne connais pas Ruby mais sa syntaxe me plait et ça fait un petit moment que je n'ai pas touché à Python mais au moins je le connais un peu.

Alors, selon vous quel est le meilleur framework web ? ;-)
  • # Forum

    Posté par . Évalué à 1.

    Oops ceci est une erreur de ma part... Serait-il possible de déplacer ça dans le forum svp ?
    • [^] # Re: Forum

      Posté par . Évalué à 9.

      houu!! La mauvaise foi...
      • [^] # Re: Forum

        Posté par . Évalué à 1.

        Non non, il ne s'agit pas de mauvaise foie... J'ai posté avec mon téléphone dans un bus. Du coup avec le petit écran, je n'ai constaté qu'il s'agissait d'un journal que trop tard...
        • [^] # Re: Forum

          Posté par . Évalué à 6.

          Excuse totalement bidon:
          L'ergonomie du site a déjà été largement éprouvée dans une boulangerie!

          ---------------------> [ ]
        • [^] # Re: Forum

          Posté par . Évalué à 3.

          fake c pa écri en sms ! ya presk pa de fote en + ! ;)
  • # Professionnel

    Posté par . Évalué à -5.

    Je te conseille d'éviter ces framework non professionnels comme RoR et Django. C'est déjà une bonne chose d'éviter PHP.

    Je te conseille d'aller voir du coté des framework JEE, comme JSF, Struts, etc...







    (Ben quoi, c'est vendredi non ?)
  • # Django

    Posté par . Évalué à 10.

    Django est LE framework web en Python. Celui qu'il faut connaître rien que pour sa culture générale. La documentation est limpide, les plugins et exemples de code pléthoriques.

    En utilisant Django non seulement tu apprendras des technologies web, mais tu apprendras aussi comment architecturer correctement une application.

    Je passe sur le fait que c'est en Python et que ça ne te fera pas de mal de progresser dans le domaine tant ce langage est utilisé partout.

    RoR te permettra de faire exactement la même chose que Django, aussi facilement. Mais Ruby ne prend pas tellement en dehors de RoR et des appli web : investir là-dedans est bien moins intéressant (sur le plan rendement de ton temps libre ou professionnel) que dans Python, sauf si c'est pour satisfaire ta curiosité et t'amuser un peu.

    Faire l'impasse sur Django serait vraiment dommage. Au moins lis la documentation en ligne des principes généraux du framework avec les modèles de données et de vues !

    Tu trouveras des sites d'hébergement gratuit de tes applications Django (chez Google entre autres).

    Amuses toi bien !
    • [^] # Re: Django

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

      Sans vouloir me faire de la pub, je signale que http://www.logram-project.org utilise Django, donc ça montre ce qu'on sait en faire (forum, wiki, pastebin, news, utilisateurs, téléchargements, etc). C'est à peu près tout ce qu'on peut trouver dans un gros site web.

      De plus, ce site web est disponible sous GPLv3 (Affero GPLv3 à partir de ce week-end, donc faut se dépêcher pour faire des magouilles avec :P ), et je reste disponible pour de l'aide (mais faut avoir bien cherché avant de me demander, je suis très occupé. steckdenis chez logram tiret project point org).

      La documentation officielle est très bien développée, le site django-snippets est excellent, on trouve une belle blogosphère autour, et c'est rapide, très rapide (j'ai eu l'occasion de tester RoR, c'est horrible ce machin, à peu près 3s pour générer une page toutes les ~100 pages, même si c'est 0,1 seconde par page ensuite).

      Sur mon Kimusufi 2XL (Un P4 mono-core hyper threading 3,2Ghz, 2Gio de RAM), avec le serveur web Nginx (que je conseille : configuré en 20 minutes en comptant la lecture de la doc, ça marche, c'est simple, puissant et rapide), je peux obtenir facilement 40 pages par seconde aux endroits complexes, une petite centaine sur les pages simples avec des templates simples. Nginx sur les fichiers statiques monte facilement à 16 000 pages par seconde !

      Bref, Django est la voie, et en une semaine, on maîtrise le bazar (expérience perso, et en plus, j'ai appris le Python en même temps que Django, comme quoi les deux sont simples et puissants).
    • [^] # Re: Django

      Posté par . Évalué à -4.

      RoR te permettra de faire exactement la même chose que Django, aussi facilement. Mais Ruby ne prend pas tellement en dehors de RoR et des appli web : investir là-dedans est bien moins intéressant (sur le plan rendement de ton temps libre ou professionnel) que dans Python, sauf si c'est pour satisfaire ta curiosité et t'amuser un peu.

      Je ne suis pas sur que Python puisse permettre de faire tout ce que fait Ruby. Sinon, il est vrai que c'est dommage que ce langage ne prenne pas tant que ça : il n'a rien à envier à Python (et Python non plus n'a rien à lui envier : ce sont deux approches différentes).
      • [^] # Re: Django

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

        > Je ne suis pas sur que Python puisse permettre
        > de faire tout ce que fait Ruby

        C'est vendredi (enfin là, plutôt samedi), mais faut pas exagérer non plus ;-)
        tu peux préciser ta pensée ?
      • [^] # Python vs Ruby

        Posté par . Évalué à 3.

        Je suis pas sur que Python puisse permettre de faire tout ce que fait Ruby.

        Tu veux dire que c’est quand même malheureux que Python n’oblige pas comme Ruby à faire des contournements foireux pour palier l’absence de destructeurs ?

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: Python vs Ruby

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

          Un exemple pour étayer ton argument ?

          Ce que j'aime bien dans Ruby que je n'ai pas retrouvé en Python, c'est la cohérence. Il y a très peu de principes à savoir en Ruby, et lorsqu'on les a saisis, on devine facilement comment va se comporter le langage dans un cas inconnu.

          Un exemple pour étayer mon propos : self n'est pas défini lors de la définition de la classe en Python. On a aucun moyen d'accéder à l'objet qu'on est en train de définir.
          • [^] # Re: Python vs Ruby

            Posté par . Évalué à 2.

            Un exemple pour étayer mon propos : self n'est pas défini lors de la définition de la classe en Python. On a aucun moyen d'accéder à l'objet qu'on est en train de définir.

            C'est quoi l'intérêt d'accéder à quelque chose qu'on est en train de définir et qui n'existe donc pas encore ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Python vs Ruby

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

              À appeler des méthodes qui s'executent sur une classe (pour créer des méthodes par exemple).

              Ensuite, à partir du moment où tu commences à définir ta classe, elle existe, tout comme le fait qu'un objet existe avant que le constructeur soit terminé. Parce que étant donné qu'on peut rajouter des méthodes à la volée, même si c'est plus galère et/ou moche en Python qu'en Ruby, ta classe n'est jamais complètement définie (au sens ou les méthodes des objets de la classe ne sont jamais figés).

              Par exemple, en Ruby, si tu fais
              def monobjet.manouvellemethode

              end

              tu crées une méthode qui n'existera que sur l'objet monobjet, et pas sur tous les objets de la même classe. Pour créer une méthode de classe, tu utilises exactement le même concept : tu crées une méthode sur la classe que tu es en train de définir.

              De même, créer une classe anonyme se fait simplement en instanciant un objet de type class. Quoi de plus logique ?
              • [^] # Re: Python vs Ruby

                Posté par . Évalué à 3.

                Ajouter dynamiquement une méthode à un seul objet :
                # contexte de test
                class C: pass
                o = C()
                # ajout
                makemethod = lambda obj, func: lambda *a, **k: func(obj, *a, **k)
                o.test = makemethod(o, lambda self, arg: 'self=%s, arg=%s' % (self, arg))
                # test
                o.test(42)

                => 'self=<__main__.C instance at 0xa1be8ac>, arg=42'

                Tu vas me dire que c'est compliqué, je te répondrai que ça ne sert quasiment jamais, alors ce n'est vraiment pas compliqué en comparaison de ce que tu essayes de faire.

                Classe anonyme en Python : type("", (), {})
                • [^] # Re: Python vs Ruby

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

                  Je n'ai pas dit que ce n'était pas possible, j'ai dit que c'était galère (ce que tu viens de me confirmer), et que c'était incohérent dans le sens ou si tout est objet, rajouter une méthode de classe ou rajouter une méthode à un objet, c'est finalement la même chose, mais ça s'écrit pas du tout pareil.
                  • [^] # Re: Python vs Ruby

                    Posté par . Évalué à 4.

                    "rajouter une méthode à un objet"
                    Rajouter une méthode à un objet uniquement, pour moi, cela va carrément à l'encontre des principes de l'orienté objet. Du coup, c'est juste un bricolage, un hack laid pour faire quelque chose qu'on a la possibilité technique de faire, même si c'est moche et ça renie la conception objet. La possibilité de le faire est presque un détail d'implémentation dont on abuse.
                    • [^] # Re: Python vs Ruby

                      Posté par . Évalué à 2.

                      Il y a un raccourci qui a été fait dans - rajouter une méthode à un objet - :

                      Dans du code propre, on inclut des méthodes dans un module, et on crée une méthode qui vient encapsuler l'inclusion de ce module.

                      On se retrouve donc avec un ensemble de méthode qui véhiculent un concept donné, que l'on applique à un objet. Cela se retrouve dans Rails avec tous les act_as_tree, has_attached_file et autres, qui viennent tout encapsuler.

                      Moralité, d'un point de vue du développeur qui utilise une telle librairie, la seule chose que j'ai à connaître c'est c'est la méthode pour intégrer les fonctionnalités et son prototype. La personne qui développe l'API peut ainsi modifier autant qu'elle le souhaite son code, faire absolument tout ce qu'elle veut tant qu'elle respecte le *contrat* passé avec le développeur, c'est à dire la méthode d'inclusion. Finalement c'est indépendant de toute forme d'implémentation, donc beaucoup plus encapsulé.

                      Je vois mal comment je pourrais arriver à une telle souplesse avec de l'héritage, avec un *contrat* si simple avec le programmeur. Cela ne me parait pas du tout être en contradiction avec le paradigme de la POO, c'est juste une différence fondamentale entre les langages dynamiques et statiques. Enfin, je comprend tout à fait ta résistance face à ce concept, je travaillais exclusivement en C++ il y a quelques années et ces concepts me faisait hérisser les poils. Et puis j'ai testé, la clarté du code qui en résulte m'a surpris au plus haut point. L'écriture de DSL d'ailleurs serait impossible sans une telle possibilité.

                      La notion de rajouter une méthode à un objet à la volée est à prendre aussi avec des pincettes dans le sens où généralement il est peu courant de le faire hors de la phase de création d'une instance. Parcourir les différentes implémentations des design patterns en Ruby est surprenant de synthétisme et lisibilité ( une fois les concepts de base maitrisés ).
                    • [^] # Re: Python vs Ruby

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

                      >> ajouter une méthode à un objet uniquement, pour moi, cela va carrément à l'encontre des principes de l'orienté objet.

                      Pas pour moi, sauf si tu considères
                      1/ que smalltalk n'est pas un bon représentant de la POO
                      2/ qu'un logiciel critique ne peut être écrit en POO (car tu t'opposes à la mise-à-jour dynamique de code [1])


                      [1] : http://portal.acm.org/citation.cfm?id=1542478 Et c'est pas un hack, t'as même un formalisme mathématique derrière…
              • [^] # Re: Python vs Ruby

                Posté par . Évalué à 2.

                "À appeler des méthodes qui s'executent sur une classe (pour créer des méthodes par exemple)."
                Tu parles de @classmethod ?
                • [^] # Re: Python vs Ruby

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

                  Pas vraiment. @classmethod, comme tous les autres décorateurs, c'est une méthode qui prend en paramètre une méthode et dont la valeur de retour (la méthode modifiée) est affectée à la place de la méthode d'origine.

                  C'est donc nettement moins souple qu'une méthode qui prend en paramètre une classe. Par exemple, je veux créer une méthode qui prenne en paramètre une classe et une chaîne de caractère, et crée plusieurs méthodes dans la classe, dont le code est basé sur la chaîne.

                  D'autre part, si un décorateur n'est rien d'autre qu'un appel de méthode, pourquoi n'est-ce pas la syntaxe d'un appel de méthode. Pour moi, et c'est très subjectif bien sûr, je trouve ça incohérent. Ça me gonfle d'avoir à apprendre quinze concepts et syntaxes pour faire des choses qui sont intrinsèquement la même notion.
                  • [^] # Re: Python vs Ruby

                    Posté par . Évalué à 2.

                    Un décorateur n'est pas une méthode.

                    Par ailleurs, tu peux très bien écrire
                    def func
                    ...
                    func = deco(func)
                    plutôt que
                    @deco
                    def func
                    ...
            • [^] # Re: Python vs Ruby

              Posté par . Évalué à 2.

              Cela sert à appliquer du code dessus pendant la définition, comme définir des méthodes dynamiquement, déclarer des attributs qui sont persistés en base facilement ( has_one, has_many dans Rails par exemple ), et toutes formes de DSL.
            • [^] # Re: Python vs Ruby

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

              >> C'est quoi l'intérêt d'accéder à quelque chose qu'on est en train de définir et qui n'existe donc pas encore ?

              Récursion, induction, co-induction…
              T'as plein de concepts sympatoches (et réellement pratiques) qui reposent sur cette possibilité.
          • [^] # Re: Python vs Ruby

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

            Franchement, c'est quand même très mal connaître Python que de dire qu'il n'est pas cohérent. Concernant ton exemple si tu parles des attributs que tu peux définir directement dans le bloc de la classe [1], c'est tout à fait logique de pas avoir accès au "self" puisque c'est là où l'on définit des attributs statiques...


            [1] Genre :
            class Truc:
            {ici}
            • [^] # Re: Python vs Ruby

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

              Si tout est objet, cela veut dire que chaque instruction s'execute dans le contexte d'un objet, et donc self doit être défini. Quand tu ouvres un interpréteur ruby, self et définit dès le départ (et est une instance de type ObjectSpace).

              Quand je crées une nouvelle classe, je ne fais qu'instancier un objet de type Class. Lorsque je la définis, je suis dans le constructeur de cet objet, et donc self est bien défini, et représente l'instance que je suis en train de définir.

              Je ne trouve pas ceci cohérent avec le principe « tout est objet » :

              stripatublu% python
              Python 2.5.4 (r254:67916, Nov 19 2009, 22:14:20)
              [GCC 4.3.4] on linux2
              Type "help", "copyright", "credits" or "license" for more information.
              >>> class Plop:
              ... pass
              ...
              >>> Plop().__class__
              <class __main__.Plop at 0x7f82a55b36b0>
              >>> Plop.__class__
              Traceback (most recent call last):
              File "", line 1, in
              AttributeError: class Plop has no attribute '__class__'


              En ruby, une classe est objet, tu peux créer une classe en appelant le constructeur de Class, et dont le scope n'est pas global. Ça, c'est cohérent avec le principe « tout est objet ».
              • [^] # Re: Python vs Ruby

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

                Python est cohérent pour cela également:


                In [12]: class Plop(object):
                ....: pass
                ....:

                In [13]: Plop().__class__
                Out[13]: <class '__main__.Plop'>

                In [14]: Plop.__class__
                Out[14]: <type 'type'>


                Toute (nouvelle) classe est sensée être déclarée comme hériter de 'object' (new style class). Une classe est donc également un objet.

                Devoir 'object' manuellement est effectivement p-e pas très joli, mais cela a été fait pour garder la compatibilité avec les versions précédentes de python. Amha, le gain "garder compatibilité avec une legere surcharge syntaxique" est nettement plus intéressant que "avoir les classes comme des objets" qui en pratique est certe joli mais moins souvent utile que une bonne compatibilité ascendante.
                Python 3k corrige cela, hériter de 'object' n'est plus nécessaire.
          • [^] # Re: Python vs Ruby

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

            Un autre exemple pour s'amuser : une méthode dont le nom commence par __ est privé, sauf si le nom se termine aussi par __. C'est tellement cohérent et intuitif qu'on dirait une règle de grammaire du français.

            stripatublu% python
            Python 2.5.4 (r254:67916, Nov 19 2009, 22:14:20)
            [GCC 4.3.4] on linux2
            Type "help", "copyright", "credits" or "license" for more information.
            >>> class Plop:
            ... def __plop(self):
            ... pass
            ... def __plop__(self):
            ... pass
            ...
            >>> plop = Plop()
            >>> plop.__plop()
            Traceback (most recent call last):
            File "", line 1, in
            AttributeError: Plop instance has no attribute '__plop'
            >>> plop.__plop__()
            >>>


            Les plus trolleurs auront remarqué le message d'erreur très explicite.
            • [^] # Re: Python vs Ruby

              Posté par . Évalué à -1.

              "Un autre exemple pour s'amuser : une méthode dont le nom commence par __ est privé, sauf si le nom se termine aussi par __. C'est tellement cohérent et intuitif qu'on dirait une règle de grammaire du français."
              T'as tellement peu d'arguments que tu en es réduit à donner tant d'importance à un tel détail ? On se demande bien qui trolle...
              • [^] # Re: Python vs Ruby

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

                C'est un détail jusqu'au jour où tu cherches pendant longtemps pourquoi ça marche pas… Et ça ne m'est pas arrivé qu'à moi…
                • [^] # Re: Python vs Ruby

                  Posté par . Évalué à -3.

                  C'est un peu ce qu'on apprend assez tôt quand on apprend Python. Si tu l'as appris n'importe comment, ne viens pas crier sur le langage.
                  • [^] # Re: Python vs Ruby

                    Posté par . Évalué à 2.

                    Enfin un langage qui évite les exceptions de ce genre, ca le rend toujours plus agréable à utiliser et à relire.

                    Faut arrêter de toujours vouloir croire que ce qu'on défend est parfait (que ca soit ruby ou python ou autre)
                    • [^] # Re: Python vs Ruby

                      Posté par . Évalué à -2.

                      Ce n'est pas parfait du tout, mais l'autre qui vient pinailler sur quelque chose qui est un détail, qui n'est même pas caché, et ne nécessite pas d'être un gourou pour le savoir, faut vraiment aimer faire chier.
      • [^] # Re: Django

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

        Je ne suis pas sur que Python puisse permettre de faire tout ce que fait Ruby.

        Je crois qu'il y a quelque chose que Ruby peut faire de base, mais que python ne peux pas (sauf avec PyPy ou d'autres, mais qui ne sont pas encore matures) c'est l'exécution d'un script d'origine non authentifiée dans un environnement restreint.

        Et je trouve que c'est important quand même. Ça permet entre autre de pouvoir utiliser des scripts python sur le web (comme JavaScript) ou pour d'autres usages similaires.
      • [^] # Re: Django

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

        >> Je ne suis pas sur que Python puisse permettre de faire tout ce que fait Ruby.

        http://en.literateprograms.org/Turing_machine_simulator_(Rub(...)
        http://dir.filewatcher.com/d/Other/src/Development/Languages(...)

        Ben si, ils savent tous les deux faire ce que l'autre sait faire…
    • [^] # Re: Django

      Posté par . Évalué à 10.

      > Django est LE framework web en Python
      Django est un excellent framework web en Python mais ce n'est certainement pas LE framework python.
      Django souffre gravement du syndrome NIH, Django n'exploite pas toutes les finesses du langage (genre les décorateurs abondamment utilisés dans CherryPy ou TG), la spécification WSGI est quasi inconnue de Django. Django est certainement un des favoris pour le titre de "LE framework web", mais probablement pas dans la catégorie "LE framework web en Python".

      Pylons et TG sont également de très bons frameworks MVC, bien documenté, réutilisant des composants existants (moteur de templates: genshi, mako, etc .., ORM: SQLAlchemy, Storm etc...), respectant la spécifications WSGI (possibilité de réutiliser les middlewares existants comme le module d'authentification de Zope Cf projet Repoze).

      Tout ces frameworks sont très bien, Django semblera plus naturel à un développeur web avec une expérience antérieure des frameworks PHP, Pylons/TG parleront plus à un développeur Python chevronné.
      Mais il y a également d'autres frameworks très bien comme le minimaliste Werkzeug.
    • [^] # Re: Django

      Posté par . Évalué à 5.

      Puisqu'on parle de Django, l'immense Django Reinhardt aurait aujourd'hui 100ans. Je vous invite à (re)-découvrir celui qui fut sans doute le plus grand guitariste du XXè siècle.
      • [^] # Re: Django

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

        N'importe quoi ! Tout le monde sait bien que c'est Slash le plus grand guitariste du XXè siecle.

        trait d'union - supérieur - crochet ouvrant - crochet fermant
        • [^] # Re: Django

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

          Je pense plutôt que c'est Hendrix ET Django, sachant que Slash sera le premier à le reconnaître pour ce qui concerne Hendrix.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Django

      Posté par . Évalué à 2.

      Django_Reinhardt est un guitariste gitan né il y a tout juste cent ans, le 23 janvier 1910. C'est son style particulier de jeu qui a donné naissance au jazz_manouche.
    • [^] # Re: Django

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

      Je rajoute une couche pour Django car je m'y mets justement et c'est purement génial. (je suis aussi un peu biaisé car je maitrise le Python)

      L'autre gros avantage de Django sur RoR, c'est que c'est très facile à installer et configurer sur un serveur de prod.

      Sur un serveur Debian, tu installes le paquet python-django, tu rajoutes quelques lignes à ta config apache pour créer un VirtualHost django (voir la doc) et c'est tout.

      Avec RoR, je n'ai jamais eu que des galères pour l'installer et les packageurs Debian s'en plaignent car c'est impaquetable, inmaintenable, …
      • [^] # Re: Django

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

        Avec RoR, je n'ai jamais eu que des galères pour l'installer et les packageurs Debian s'en plaignent car c'est impaquetable, inmaintenable, …

        Si tu parles de http://pkg-ruby-extras.alioth.debian.org/rubygems.html, c'est quand même pas auusi noir que tu le laisses entendre...

        Surtout que depuis que passenger existe (et il est dans Debian), déployé une appli rails est devenu un jeu d'enfant.
        • [^] # Re: Django

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

          Ben déjà, la situation a déjà progressé depuis la dernière fois que je m'y suis mis. (point pour toi)

          Mais malgré tout, c'est de nouveau un truc en plus à apprendre dont je n'ai rien à faire. Gems ? Passenger ? Je ne veux pas savoir ce que c'est, je veux faire soit apt-get install (pour les librairies), soit placer du code en user space (pour les développements maison). Je veux que mon code 3rd party soit automatiquement à jour au niveau sécurité, je ne veux pas de traitement de faveur ni me prendre la tête.

          Ce que Django permet de faire très facilement et très proprement. J'en suis très heureux.


          Note que, bien qu'étant un inconditionnel de Python, j'adresse également la même critique aux eggs de Python, qui sont à mes yeux une horreur tout comme les gems.


          Je rajoute un autre bénéfice de Django : tu peux utiliser toutes les libs Python (xmpp, reportlab,…) bref, c'est le bonheur.
          • [^] # Re: Django

            Posté par . Évalué à 2.

            J'ai un peu du mal avec la logique - ne pas se prendre la tête -, je me vois mal avoir ce genre d'attitude en déployant en production une application mais soit, à un certain niveau d'utilisation je peux comprendre que cela soit un argument, surtout si c'est pour apprendre à utiliser un framework.

            ( quoi que je ne trouve pas que ./script/server soit particulièrement compliqué dans ce contexte )

            Par contre, je ne saisis pas ta dernière remarque, tu peux tout à fait utiliser toutes les gems que tu souhaites depuis ton application RoR, à vrai dire, il n'y a quasiment plus de plugins aujourd'hui, tout est livré sous forme de gems (librairies) donc.
            • [^] # Re: Django

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

              Les librairies python, à la différence des gems, sont des packages debian comme les autres.

              Pourquoi "mettre en prod" devrait-il être synonyme de "se prendre la tête" ?


              Mon raisonnement est tout simple :

              Est-il possible de maintenir un serveur Django (sécurité, mises-à-jour) sans rien connaître de Django ou même Python ?

              Oui, tout à fait. Il suffit d'installer les bons paquets avec apt-get. Seule contrainte : une config apache particulière pour les VirtualHosts django. Une fois que t'as cette config, tu n'as même pas besoin de savoir que django tourne : tout est géré avec apt-get upgrade.

              Point barre.

              Essaye de me faire la même chose avec RoR. Impossible (du moins lors de mes essais).

              Je ne veux pas des gems, des eggs ou des brols de ce genre. Je veux apt-get.

              D'ailleurs, ça a toujours été le gros reproche que j'ai entendu à propos de RoR : c'est génial pour les développeurs mais un cauchemar pour les administrateurs.

              RoR a le grand mérite d'avoir ouvert une voie, d'avoir popularisé une nouvelle approche. Mais, d'un point de vue purement pragmatique, il me semble que pour un nouveau qui débarque, se mettre à un framework Python ou Php me semble beaucoup plus logique et plus rentable.
              • [^] # Re: Django

                Posté par . Évalué à 2.

                Passenger fournit une utilisation aussi simple que celle que tu décris ( comprendre à coup de Vhost bêtes et méchants ).

                Concernant les gems / paquets debian c'est clairement une horreur dans l'état actuel des choses. Le problème c'est que Ruby de manière générale voit son écosystème évoluer très très rapidement. Peu d'acteurs majeurs se posent la question du : est-ce que c'est bien packagé ? pour développer, c'est d'ailleurs ce qui permet à ce petit monde d'avancer aussi vite et de voir des librairies se voir régulièrement remplacée par des versions plus évoluées, plus pratiques ou plus claire.

                Clairement, c'est un problème à gérer coté déploiement.

                Personellement, après m'être arraché les cheveux, j'ai décidé de fournir mes applications directement avec toutes les dépendances bundlés dans l'appli ( non je ne suis pas un sale qui a tout cela sur son repository, juste dans mon script de déploiement je freeze tout ), ainsi c'est moi qui prend en charge cette partie, vu que moi, développeur j'y comprends quelque chose ( à tout ce bazar ^^). Oui, c'est moins élégant, mais cela fonctionne diablement mieux en pratique ( et le sysadmin peut reposer ses cachets de Xanax ). A administrer c'est update de passenger, ruby éventuellement et ... c'est tout (avec apt-get hein). Le pire c'est qu'une telle solution, c'est une seule commande pour le développeur.

                Ror était un tel cauchemar avant Passenger, je t'invite à lire juste un howto Debian pour constater à quel point cela peut être simple aujourd'hui.

                Enfin ma réponse à ta dernière opinion peut être considéré comme du troll, mais il me semble que le point innovant à proprement parler est Ruby et sa philosophie, pas juste un framework ou deux. Je n'ai pas les moyens de l'expliquer de manière concise, aussi je ne m'aventurerais pas à le faire, juste je pointe dans une direction si cela t'intéresse d'approfondir ta réflexion.
              • [^] # Re: Django

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

                > Les librairies python, à la différence des gems, sont des packages debian comme les autres.
                lapincompris
                tu compares quoi ?
                les egg et les gems ?
                un egg n'est pas un paquet debian, si ?

                Tu sais, certaines distrib package des lib ruby hein... si c'est pas bon chez toi faut ptetre regarder ailleurs.

                > Essaye de me faire la même chose avec RoR. Impossible (du moins lors de mes essais).

                ben je sais pas, genre :
                # aptitude install apache rails mongrel
                # viemacs /etc/apache2/sites-available/monsite
                # /etc/init.d/apache restart

                Ca ne convient pas ?
                • [^] # Re: Django

                  Posté par . Évalué à 1.

                  Ce que je pense qu'il critique c'est qu'en théorie, les gems fonctionnent une fois packagé, mais les versions sont assez outdated, surtout dans un monde Rails où beaucoup fleurtent avec les dernières versions, ce qui pose souvent problème dans la pratique.

                  Personnellement sur *mes* debians je mets Ruby EE et je m'abstrais du système de paquetage.

                  Sur celle de mes clients, je freeze tout dans l'appli comme je l'ai décris au dessus, et je reste sur le ruby du système.

                  Par contre oui, la procédure que tu décris est très simple, et peu semble en avoir entendu parler ...
                • [^] # Re: Django

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

                  > # viemacs /etc/apache2/sites-available/monsite

                  Quoi ????!!

                  Tu n'utilises pas Vim ???!!!












                  Ok, je -----> []

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: Django

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

                    non non, je continue à muscler mes 3610 doigts

                    (véridique en plus, c'est mon oséditeur de texte principal au boulot)
  • # pour ma part j'ai choisi ROR et je le conseille ...

    Posté par . Évalué à 1.

    Par contre évite de faire les mêmes erreurs que moi :
    - il faut suffisamment connaître Ruby et ses "astuces" pour pouvoir apprécier Rails. Je suis passé à rails en ne connaissant pas Ruby et certaines choses me sont passés par dessus. Ruby est assez facile à apprendre (surtout si tu connais Python).
    - si tu achètes un bouquin, assure-toi que la version de Rails que tu installe est bien celle qui est utilisée par l'auteur du bouquin. Pour ma part je me suis fait avoir: j'ai installé un Rails 2 alords que mon bouquin causait en Rails 1.8 (de mémoire). J'ai perdu du temps sur des différences subtiles.
    - chaque mot d'une doc Ruby est important, bien pesé; Il ne faut pas survoler la doc ou un bouquin mais bien la lire. Pour ma part, j'ai parfois tendance à survoler certaines parties d'une doc lorsque je cherche des infos pour ne me concentrer que sur le point qui m'intéresse. Avec Rails ça a été une erreur. Pourquoi ? Parce que Rails adopte le principe "convention plutot que configuration", et en lisant rapidement je suis passé à coté de certaines de ces convention, notamment lorsque j'ai voulu aborder les relations de plusieurs à plusieurs (les tables permettant d'effectuer la relation doivent être créées de façon précise : le nom des deux tables à joindre, mais par ordre alphabétique. Je n'avais pas prêté attention à l'ordre de création, me concentrant sur le reste et j'ai passé deux jours à chercher pourquoi ça ne marchait pas). Par contre quand tu te fais avoir une fois, après tu n'oublies plus.

    Si tu as fait du Python, tu apprendras vite Ruby. Il faudra juste changer un peu certaines habitudes. Pour ma part j'ai trouvé que Ruby était une libération par rapport à Python, sans être non plus un truc trop permissif comme Perl.

    Un bouquin que je te conseille : les design pattern en Ruby ( http://designpatternsinruby.com/section01/ab_reviews.html - il en existe une traduction française ). Tres bon bouquin pour qui veut se mettre à Ruby et/ou à Rails. Il ne parle pas expressement de Rails mais permet de comprendre ce quise passe sous le capot de Rails.

    Pour Rails en lui même je ne sais pas trop quel bouquin conseiller.
  • # Merb et Rails

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

    > Quoi qu'il en soit, j'ai aussi repéré Pylons, TurboGears ou encore Merb

    Je te déconseille de partir sur Merb. C'est un très bon framework, mais peu documenté, et surtout, qui ne va plus évoluer. Les équipes de Ruby on Rails et de Merb ont décidé il y a un an d'unir leurs efforts pour fournir une nouvelle version majeure de Rails qui fournirait le meilleur de Rails et le meilleur de Merb.

    Depuis, Merb et la branche stable de Rails (Rails 2.3) ont très peu bougé, les développements se sont concentrés sur Rails 3, dont une version beta devrait sortir d'ici peu (première quinzaine de février dit ma boule de cristal).

    Comme très peu de personnes ont essayés Rails 3 pour le moment, il est encore assez difficile de savoir si Rails 3 sera une grand réussite ou un flop. Les premiers articles que l'on commence à voir sont très enthousiastes et montrent que l'API de Rails a profondément évolué entre Rails 2.3 et Rails 3. Il faudra donc sûrement réapprendre pas mal de choses pour suivre ce changement, et il serait donc dommage d'acheter maintenant un livre sur Rails. Par contre, ça me semble être une bonne période pour apprendre Ruby ;-)
  • # Turbogears et grails

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

    J'ai réalisé recement 2 projets pro, un gros avec Turbogears (abrévié TG dans un commentaire), l'autre plus petit avec Grails (J2EE en language Groovy). Grails me parait très interessant, je l'utiliserai certainement encore à l'avenir.

    Ils sont finalement très proche en philosophie, ils permettent de construire rapidement une appli puissante et sur mesure.
    - l'architecture MVC est bien concu avec tout ce qu'il faut (moteur de templation, ORM, ...)
    - On défini exactement le modèle (objet et relationnel) de chacun de ses objets metiers et les relations entre elles, et on dispose d'un ORM performant.
    - Ils disposent de nombreux plugins pour ne pas reinventer la roue à chaque fois
    - Ils sont documentés
    - Ils sont tres productif, le langage est peu verbeux, ça va vite, le code est élégant avec peu de (mauvaises) surprises
    - Les deux embarquent un serveur web et une base de donnée, pour aider en phase de dev

    Ensuite, + spécifiquement:
    - Turbogears pose quelques soucis: Depuis la sortie de TG 2.0, pleins de docs, y compris l'officiel, ne sont plus a jours, les tutoriaux non plus. Y'a souvent besoin d'aller voir le code source de TG pour s'en sortir, les plugins dispo sont souvent pas fini ou au stade "proof on concept" et faut parfois bidouiller un peu... Y'a un domageable coté "couscous" dans tout ce qui tourne autour du truc.
    Maintenant, y'a toujours moyen de s'en sortir (surtout qu'on avait un pro de TG dans l'équipe), on a pas rencontré de limitations par le framework lui meme qui est franchement bien conçu (a commencer par les décorateurs par exemple).

    - Grails a pour lui une base de plugins de grande qualité, installable aussi facilement qu'un plugin firefox, une doc et des tutoriaux à jour, ... L'archi me semble ultra saine, l'ORM est performant, ....
    L'avantage pour moi est quand meme qu'il s'agit de J2EE, on a acces à l'immense bibliotheque existante, l'acceptation dans le milieu professionnel (là ou Python aura plus de mal a passer), l'integration dans des ensemble plus grand.... Bref, une grande ouverture d'utilisation.
    L'avantage du Java/J2EE... mais sans les inconvenient. C'est rapide, pas verbeux, et pas de soucis d'architecture ou de prise de tete concernant les design patern... vue qu'elle est déjà faite ;) De quoi se réconcilier, à titre perso, avec le J2EE. Voir d'en tomber amoureux.
    Le seul truc, pour etre fair play, c'est que je n'ai pas poussé autant dans les retranchement Grails que Turbogears, notamment ce qui serait l'équivalent des décorateurs.

    Bon, coté plugin de grails, je ne peux pas ne pas citer:
    http://www.grails.org/plugin/class-diagram
    qui genere un diagramme UML de ta réalisation, forcement à jour donc ;)
    • [^] # Re: Turbogears ...

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

      J'avais fait un comparatif l'an dernier pour le boulot pour savoir quelle solution choisir. Les contraintes étaient :

      - utilisation de notre technologie disponible sous forme de bibliothèques dynamiques,
      - utilisation d'un ORM pour s'affranchir (autant que faire se peut) de la couche SQL,
      - services web en SOAP,
      - application web d'administration,
      - Réutilisation maximale du code entre les différentes applications (on a développé un SI qui tourne avec une trentaine de machines, gérant chacune des services spécifiques).

      PHP, on l'a mis de côté, notamment parce l'utilisation de bibliothèques dynamiques nécessite de coder des plugins (pas en langage interprété).

      Finalement on utilise :
      - TG2 pour la partie application web. L'intérêt c'est notamment qu'il utilise des modules indépendants comme SQLAlchemy pour la partie ORM qui est super bien fait (hormis des "problèmes" de cache pas toujours évident)
      - CherryPy / Soaplib pour les services SOAP (et suds pour la partie clients SOAP)

      Ca permet notamment de réutiliser SQLAlchemy sur tous les logiciels qu'on a du développer, que ce soit pour les démons de backoffice, les services SOAP, les applications web.

      Si tu te limites au "web", je ne sais pas si python est le plus adapté, si tu fais un peu de tout, clairement c'est une force. Notamment pour ses capacités d'introspection.

      Un exemple : on a une classe qui centralise tous les codes d'erreur et les messages associés. Elle est utilisée "classiquement" par l'ensemble du code ; l'introspection permet également de générer à la volée une page web qui liste tous les codes d'erreur. Tout ça en ayant "codé en dur" les messages et codes d'erreur (j'aime pas le principe qu'un code d'erreur soit "paramétré dans un fichier : tu peux pas assurer qu'il ne sera pas modifié "involontairement" ou tout simplement "à jour...)

      Les seuls points noirs avec python c'est à mon avis :

      - qu'il n'est pas typé (ta variable peut être du texte, un objet, etc sans que tu puisses garantir qu'il restera toujours du même type
      - Qu'il n'y a aucun moyen de savoir si ton code est valide à moins de faire des tests de tous les cas de figure. Exemple : un log mal formatté qui est affiché dans les cas vraiment exceptionnels ne sera pas détecté squf lorsque ce cas exceptionnel intervient (ie en prod dans un cas de figure improbable et ça te génère une exception qui peut potentiellement faire planter tes services).

      Mais pour revenir au sujet original, TG2 est vraiment agréable à utiliser et super flexible.
      • [^] # Re: Turbogears ...

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

        Pour préciser un peu Turbogears 2 ; il est basé sur :
        - Pylons pour la partie web,
        - SQLAlchemy pour la partie "abstraction de base de données"
        - Genshi pour les templates HTML
        - ToscaWidgets pour la génération / validation de formulaires
        - repoze pour l'authentification

        Tout ceci est "par défaut" ; il est tout à fait possible de changer les technologies sous-jacentes en fonction de tes besoins / connaissances.

        Personnellement, je vois TurboGears comme un "packaging" de différentes technologies qui sont au top dans leur domaine. Ca rejoint un peu la philosophie Unix : une agglomération d'outils qui font une seule chose mais qui la font bien.
      • [^] # Re: Turbogears ...

        Posté par . Évalué à 2.


        Les seuls points noirs avec python c'est à mon avis :

        - qu'il n'est pas typé (ta variable peut être du texte, un objet, etc sans que tu puisses garantir qu'il restera toujours du même type
        - Qu'il n'y a aucun moyen de savoir si ton code est valide à moins de faire des tests de tous les cas de figure. Exemple : un log mal formatté qui est affiché dans les cas vraiment exceptionnels ne sera pas détecté squf lorsque ce cas exceptionnel intervient (ie en prod dans un cas de figure improbable et ça te génère une exception qui peut potentiellement faire planter tes services).

        Certes ce n'est pas intégré au langage, mais il y a quand même des outils pour ça : le module typecheck pour forcer les types, pychecker pour la vérification du code, et certainement d'autres encore.
        Après, je sais qu'ils existent, mais je ne les ai jamais utilisés... parce que je n'en ai jamais senti le besoin !
  • # Wicket

    Posté par . Évalué à 2.

    Si t'as un quelconque interet a aller voir du cote de java, mon manager ne me dit que du bien de wicket.
    Bon, j2ee tout ca, si t'as des besoins simples, ca va probablement prendre une enclume pour ecraser une mouche, mais sait on jamais.

    Personnelement, le html me donne des boutons, donc plus je m'en eloigne, plus je suis content, donc j'ai pas d'avis a en donner, mais on l'utilise sur l'autre projet de la boite, les devs en sont tres content, ca rend bien et ca a l'air bien gaule.
    Une bonne archi coherente et tout, une bonne doc, bref, apparement ca marche bien.
    • [^] # Re: Wicket

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

      Moi, tout aussi personnellement, c'est le Java qui me colle des furoncles. Java ou comment écrire un truc qui écrit un truc [...] qui écrit un truc qui écrit du html....
      • [^] # Re: Wicket

        Posté par . Évalué à 3.

        D'ou ma phrase:

        Bon, j2ee tout ca, si t'as des besoins simples, ca va probablement prendre une enclume pour ecraser une mouche, mais sait on jamais.

        j2ee c'est fait pour rendre des trucs tres compliques faisables et maintenables.

        Apres si certains architectes ont tendance a abuser de la coc' et des design pattern pour faire des factory de factory et finissent avec plus d'interfaces que de concrete classes, c'est pas trop la faute du langage/framework, plutot des architectes en question.
        J'en ai vu des merdes de ce genre, une particulierement rigolote de chez ft r&d qui consistait a reimplementer les pipelines cocoon dans une instance de cocoon (qui ne definissait evidement qu'un seul pipeline avec une seule action), et qui avait entre autres perles un genre factory, mais pas vraiment, avec un switch case de 700 lignes.
        Les attrocites, ca s'ecrit dans n'importe quel langage.
        Etonnament, c'etait un des projets avec le plus gros turnover de la ssii, il servait beaucoup a boucher les intercontrats. Et apres on s'etonne que l'appli soit un monstre a 6 tetes.

        J'ai aussi vu des trucs tres bien ecrit, tres clair, sans design pattern a la con juste pour le principe de cocher la case "design pattern".


        La principale difference avec php/python/ruby et autre, c'est que la nature non typee/non compilee de ces langages fera que ton projet petera de partout avant que t'aies pu finir ton usine a gaz...
        • [^] # Re: Wicket

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

          "j2ee c'est fait pour rendre des trucs tres compliques faisables et maintenables."


          Je nuance :

          1) Un programmeur J2EE, c'est fait pour transformer un problème simple en un "truc" très compliqué.
          2) J2EE c'est fait pour faire croire à un chef de projet que le truc très compliqué est faisable.

          Bonus :

          3) J2EE permet de créer de l'emploi en permettant à autant de personnes que le budget le permet de travailler non-stop et d'être productif sans que le projet initial n'avance d'un iota.

          https://linuxfr.org//~ploum/27723.html
          • [^] # Re: Wicket

            Posté par . Évalué à 1.

            Ca sent le troll velu mais

            > "La principale difference avec php/python/ruby et autre, c'est que la nature non typee/non compilee de ces langages fera que ton projet petera de partout avant que t'aies pu finir ton usine a gaz..."

            C'est quand même le vieil opinion sans argument juste pour essayer de clôturer un débat qu'on sent perdu d'avance.

            Dans le même genre je peux en faire aussi : Non J2EE n'est pas une solution web correcte. Quoique qu'on fasse, pour rendre l'application performante avec une bonne montée en charge, il faudra le double d'investissement en exploitation qu'un projet en PHP,Python, Perl et autre.
            • [^] # Re: Wicket

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

              j'étais en congé vendredi, faut bien que je me rattrape ;-)
              • [^] # Re: Wicket

                Posté par . Évalué à 2.

                C'était plus au message de the_dude auquel je faisais référence.
                Le tiens n'avait pas besoin d'être libellé comme tel pour clairement apparaître comme un bon gros troll :)
  • # pourquoi pas en php ?

    Posté par . Évalué à -2.

    Pourquoi exclure par principe les Framework en PHP (genre Zend Framework par exemple) ?
  • # Pour apporter ma pierre

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

    J'aurai tendance à conseiller django (doc, support, communauté et eco-système très complet).
    Cependant, regarder du côté du pure WSGI peut être interessant. Je suis un adepte du http://pythonpaste.org/do-it-yourself-framework.html , et de la réutilisation ;-)
    Il y a toutes les briques en WSGI, pour faire exactement ce que tu veux.

    Pour le R/W de tag id3/ogg/ape, mutagen sera parfait
    http://code.google.com/p/quodlibet/wiki/Development/Mutagen
  • # Play

    Posté par . Évalué à 3.

    J'étais orienté depuis longtemps sur Ruby on Rails que je trouve génial, mais très frustrant par ses innombrables plugins pas toujours maintenus. J'ai découvert Play! ici même et je trouve ce framework très très rafraichissant : http://www.playframework.org/
  • # SPIP ;o)

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

    Ca va peut être en faire hurler certains, mais je vois SPIP plus comme un framework que comme un CMS.

    On fait tout et n'importe quoi avec du SPIP. il possède son propre langage de programmation même si c'est du php derrière.

    Je m'en sers pour faire à peu près tout ce dont j'ai besoin :
    - site de chat (ajax)
    - sites institutionnels multilingues
    - base de données en ligne
    - blogs (allant jusqu'à prendre en charge les mêmes thèmes que dotclear)
    - génération de flux xml pour applis smartphone
    etc...

    Et puis c'est libre et il y a une forte communauté derrière.

    ;o)
    • [^] # Re: SPIP ;o)

      Posté par . Évalué à 0.

      J'utilise Spip et RoR et franchement ça ne me fait pas hurler.

      <BOUCLEma_vie(BREVES_DE_COMPTOIR){id_de_pourquoi_tu_lui_parle_de_spip_toi?}>

      Après ça va dépendre de ses besoins. Apprendre le langage de boucles, parcourir la doc de l'api pour coder en 45 minutes ce que tu fais en 10 avec RoR ce n’est pas forcement intéressant.

      Parce que bon, fondamentalement Spip est un bon CMS, l'utiliser comme un framework est souvent une perte de temps. Après, Spip dispose de tellement de fonctionnalités et plugins qu'il est très rare de devoir l'utiliser comme un framework/ et ou utiliser un véritable framework.

      </BOUCLEma_vie>
  • # moi j'aurai tendance...

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

    à me méfier des personnes qui te donnent des conseils sans avoir un minimum d'informations sur le site que tu veux faire.

    C'est un site où tu auras beaucoup de données à gérer ? quel traffic tu comptes avoir ?

    Il y a plusieurs critères à prendre en compte, les langages que tu maitrises (effectivement, ça sera plus simple de faire du TurboGears ou du Pylons), l'aide que tu peux avoir de la part de la communauté (les forums autours de RoR sont plus nombreux qu'autours de Merb), ce que tu connais déjà (si tu connais bien le PHP, il existe le PSP qui est l'équivalent en python, je travaille beaucoup avec ce langage... mais si tu n'y connais rien, autant utiliser des frameworks haut niveau...)

    Axel
    • [^] # Re: moi j'aurai tendance...

      Posté par . Évalué à 1.

      Sur le premier projet que je vais créer il n'y aura pas beaucoup de personnes qui s'y connecterons. Il s'agira d'une interface permettant aux personnes autorisées (Identifiants et SSL) d'uploader des fichiers audios avec les tags qui vont biens. L'interface offrira la possibilité d'éditer les tags afin de corriger le fichier.

      Une fois les fichiers correctement édités, les informations contenues seront (sûrements) validés par les autres avant d'être introduite dans la base de données. La base permettra ensuite de retrouver les fichiers rapidement en les classant comme la plupart dans lecteurs audios actuel (Genre, artiste, titre, etc...).

      La deuxième partie du projet sera de rendre accessible cette base et là il devrait avoir un peu plus de traffic.
  • # HAppS ou HappStack

    Posté par . Évalué à 2.

    Real Men Use Functional Programming : http://happs.org/ http://happstack.com
  • # Lift

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

    Personne n'a encore cité Lift : http://liftweb.net/

    C'est un framework qui tourne sur la JVM mais qui utilise Scala comme langage. Comme Scala est un des langages les plus intéressants, est statiquement typé et supporte les XML litterals (du XML directement dans le code), ça doit fonctionner plutôt bien (pour être honnête, je ne l'ai jamais utilisé, je ne fais pas de développement web).
  • # Ma pierre…

    Posté par . Évalué à 3.

    Salut,

    Pour apporter ma pierre…

    Dis toi qu'un framework est une chose complexe à maîtriser de bout en bout. Par conséquent, si tu souhaites partir sur un framework, choisis-en un une bonne fois pour toute, car il te faudra un certain temps avant d'être vraiment productif (genre, je code à la vitesse de l'éclair sans regarder la doc toutes les 30 secondes).

    Après, tous les plus grands frameworks (Django, RoR, Symfony) se valent plus ou moins, et ont chacun leurs avantages et leurs défauts. Si quelqu'un te dit que le framework XXX est vraiment-meilleur-que-les-autres-c'est-celui-la-qu'il-faut-prendre-sans-réfléchir, c'est sans doute qu'il ne sait pas de quoi il parle.
  • # ou pas

    Posté par . Évalué à 4.

    Jsuis pas dev web, mais j'ai eu parfois le besoin de faire des applis web
    Perso, en framework web je ne connais que rails et seaside (en smalltalk)

    Je ne te conseillerai pas seaside car écrit dans une langage que (malheureusement) tu trouveras encore moin que ruby.
    Néanmoins je le préfére à rails pour une raison: un modèle objet bien plus cohérent: en rails tu as beaucoup plus de "magie" et donc un peu plus de difficultés à comprendre comment tout s'emboite en interne, en seaside chaque objet a son modèle, son contrôleur et sa vue (ça reste clair, vu que smalltalk comporte un très bon ide et sépare le tout en protocole), on voit bien comment tout s'emboite.

    voila, juste une petite critique sur rails
  • # cubicweb

    Posté par . Évalué à 1.

    Ave,

    Y'a une petit SSLL française, Logilab, qui produit un CMS sémantique prometteur : cubicweb http://www.cubicweb.org/ . Ça a l'ait bien architecturé et c'est en python.

    Étienne

Suivre le flux des commentaires

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