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.
Aller plus loin
- Dancer (336 clics)
- Dancer sur GitHub (41 clics)
- PSGI (26 clics)
- OSDC.fr (266 clics)
- Réunion Dancer (25 clics)
# Perl combien?
Posté par djano . Évalué à 0.
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 Sytoka Modon (site web personnel) . Évalué à 5.
[^] # Re: Perl combien?
Posté par Nicolas Legrand (site web personnel) . Évalué à 6.
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 Franck Cuny . Évalué à 4.
# Questions naives
Posté par maximegb . Évalué à 1.
[^] # Re: Questions naives
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Questions naives
Posté par jhc_ . Évalué à 4.
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 Bruno Michel (site web personnel) . Évalué à 3.
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 bruno212 . Évalué à 2.
[^] # Re: et Jifty ?
Posté par Yves Agostini (site web personnel) . Évalué à 1.
donc
apt-get install jifty
[^] # Re: et Jifty ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
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 JohnnyBar . Évalué à 1.
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 LupusMic (site web personnel, Mastodon) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.