Dancer, un framework Web en Perl

Posté par (page perso) . Modéré par baud123.
Tags :
12
2
sept.
2010
Perl
Dancer est un framework Web écrit en Perl, initialement inspiré par Sinatra (Ruby). Le projet, après un an de développement, a maintenant sa propre identité.

Dancer est très facile à installer, son nombre de dépendances étant limité au strict minimum. L’objectif principal est de rester simple à prendre en main pour un novice en Perl. Mais il est également assez souple pour qu’un utilisateur expérimenté puisse accomplir tout ce qu’il souhaite. Une de ses forces est de s’être construit dès le début autour de l'écosystème PSGI, le port de WSGI/Rack en Perl.

Parmi ses fonctionnalités, on peut citer :
  • Prise en charge de différents systèmes de sérialisation (JSON, XML, YAML), idéal pour développer des applications ReST ;
  • Un système de greffon ;
  • Compatibilité avec Plack et ses nombreux middlewares ;
  • De nombreux systèmes de loggers et de templates disponibles.

Des présentations sur Plack et Dancer sont annoncées pour la conférence OSDC.fr. Et le dernier jeudi de ce mois de septembre, le 30, une réunion des utilisateurs/développeurs de Dancer est prévue sur Paris pour faire des démonstrations et discuter/échanger.
  • # Perl combien?

    Posté par . Évalué à 0.

    J'ai peur de déjà connaître la réponse, mais je suppose que c'est écrit en Perl 5? Si c'est le cas, je me demande si les développeurs n'auraient pas mieux faire de s'attaquer directement au Perl 6 pour trouver des bugs et être parmi les premières applications écrites dans ce langage? Peut être que l'utilisation de bibliothèques existantes les bloque sur Perl 5?

    Pour ceux qui comme moi ne connaissent pas Plack: http://en.wikipedia.org/wiki/Plack_%28software%29
    Il s'agit d'une implémentation de PSGI (équivalent Perl du pythonique WSGI) très inspirée du rubyesque Rack qui est framework de développement d'application Web.
    • [^] # Re: Perl combien?

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

      La dynamique de Perl6 a relancé la dynamique Perl5 donc la mise au point de bon environnement en Perl5 sera bénéfique à Perl6. Bref, tout le monde est gagnant.
    • [^] # Re: Perl combien?

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

      Bha, Perl 5 a encore de beaux jours devant lui, pourquoi voudrais-tu qu'un travail commencé il y a un an l'ait été avec un langage toujours en cours de développement et pas/peu packagé pour la plupart des systèmes ?

      Les projets en Perl 6 arriveront, mais faut laisser le temps au temps :). Le temps de pouvoir partir d'un pkg_add -i perl6 ou un aptitude install perl6 déjà.
    • [^] # Re: Perl combien?

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

      Martin Berends (sur github) a commencé à travailler sur un port en Perl6. Pour le moment il s'occupe de HTTP::Server::Simple, et l'objectif est d'avoir rapidement une premiere version de Dancer pour Perl6, pour que les gens curieux qui testent rakudo puissent commencer à avoir un framework web.
  • # Questions naives

    Posté par . Évalué à 1.

    Comment ça se situe par rapport à Ruby on Rails ? Et surtout, quelles sont les avantages et les inconvénients d'un framework web très complet par rapport à un framework web plus léger, quels sont les critères pour choisir ?
    • [^] # Re: Questions naives

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

      Tu aurais pu attendre demain.
    • [^] # Re: Questions naives

      Posté par . Évalué à 4.

      Comme écrit dans la news, c'est inspiré de Sinatra, donc typiquement simple et rapide à écrire, tant que tes besoins restent précis et bien déterminés. Après, n'ayant pas utilisé Dancer, je peux pas t'en dire plus.

      Pour ce qui est du framework léger, personnellement, je trouve cela particulièrement efficace à maintenir, quand il s'agit d'un site qui remplit une petite paire de fonctionnalités, ou typiquement un webservice. Et c'est violemment rapide à écrire. Etant utilisateur de Rails et Sinatra, je réparti essentiellement en fonction de différent critères :

      - est-ce que le site rempli une seule et unique fonction ? ( ex : un blog, ca stream juste des articles en opposition au dernier Facebook-like que ton client veut implémenter pour permettre à ses employés de s'échanger moultes stratégies business )
      - est-ce que le site est touffu ? au sens des fonctionnalités, un blog avec des catégories, archive non, un blog avec intégration machin facebook, twitter, flux rss, gestion de pages façon CMS, multi-user => Rails
      - est-ce que la personne a l'origine du projet est atteinte de featurite ( envie régulière et soudaine d'ajouter des fonctionnalités ) : le site va devenir vite un beau bordel, le code va tendre vers le point de rupture : le moment où je vais réécrire dans Sinatra des morceaux similaire à ce qui est fait dans Rails.

      Honnêtement, les deux premiers points sont assez triviaux à déterminer une fois que l'on a joué avec le lourd et le léger, autant le troisième est assez particulier à appréhender. Le pire étant le moment où tu te dis, merde j'aurais du écrire ça en Rails ( ou Django, ou ce que tu veux, pourvu que ce soit lourd ).

      Bref, c'est un peu comme tout, si tu te plantes d'approche, tu vas douiller, et tout faire avec le lourd, c'est faire un pas vers la médiocrité, vu que tu sauras jamais quand utiliser le léger et profiter de ses avantages. Faut prendre des risques, et accepter de se planter : projets perso/internes pour apprendre à choisir.
    • [^] # Re: Questions naives

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

      Je ne connais pas Dancer, mais je vais m'appuyer sur mon expérience de Rails vs Sinatra pour répondre.

      Un framework léger, comme Dancer et Sinatra, c'est bien pour :
      * faire rapidement un petit site de démo, un proof of concept, essayer rapidement quelque chose (exemple : essayer redis lors d'un atelier d'une demie-journée)
      * ajouter une interface web à une application existante (exemple : gembox fournit une interface web pour consulter la doc des gems Ruby et son code réutilise intelligemment Rubygems)
      * développer une application avec un nombre limité de fonctionnalités, surtout si elles ne s'appuient pas sur une base de données (exemple : Gollum, un wiki qui utilise un dépôt git)

      Par contre, Rails est bien mieux adapté pour un site web avec pas mal de fonctionnalités et qui va évoluer dans le temps. En gros, dès que l'on pense que l'on va avoir plus de 3 ou 4 fichiers, Rails apporte une structuration intéressante là où ça peut vite devenir le bordel avec Sinatra.
  • # et Jifty ?

    Posté par . Évalué à 2.

    Dans les framework web pour Perl, il y a aussi Jifty (http://www.jifty.org), dont l'utilisation est presque confidentielle. C'est bien dommage, car il est très bien fait. Mais bon, c'est un peu normal, en général, un framework perl, ça implique l'installation de la moitié du CPAN, et tout le monde ne peut pas se le permettre...
    • [^] # Re: et Jifty ?

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

      c'est packagé debian / ubuntu
      donc

      apt-get install jifty
    • [^] # Re: et Jifty ?

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

      > l'utilisation est presque confidentielle

      Il faut dire que même sur les sites Perl, on en parle pas beaucoup et il y avait une certaine dynamique au début mais on a l'impression que c'est un peu mort. En tout cas, c'est mon impression lorsque je vais sur le site web...

      Le concurrent de dancer est actuellement mojolicious qui a zéro dépendance sur le CPAN.

      http://mojolicious.org/
      • [^] # Re: et Jifty ?

        Posté par . Évalué à 1.

        Le fait que Mojo ne dépende d'aucun module CPAN me fait plus peur qu'autre chose. Ils ont tout réécrit, et cela va à l'encontre même du principe de "Do not repeat yourself".

        Un serveur web embarqué dans le code de Mojo m'inquiete plus qu'une dépendance sur HTTP::Server::Simple

        L'attitude puérile du leader de Mojo "sri" (qui a fait une campagne de "marketing" visant à basher Dancer et ses développeurs) m'a aussi incité à choisir Dancer.
        • [^] # Re: et Jifty ?

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

          DRY ne s'applique pas dans ce cas là, puisqu'ils ne répètent pas eux-même. Ils appliquent plutôt le DIY ;)

Suivre le flux des commentaires

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