Je suis tombé récemment sur Sinatra, sûrement grâce au blog de oz ou à celui de sa société, j’ai trouvé l’idée amusante, et même plutôt brillante.
Bon on ne se refait pas, je dois avoir chopé une sorte de maladie qui fait que j’aime réécrire des trucs en Perl, ça commence à devenir inquiétant diront certains, probablement, mais tant que ça m’amuse je ne vois pas pourquoi arrêter.
Bon venons-en au fait, j’ai un script bin/mawebapp.pl :
#!/usr/bin/perl
use Dancer;
get '/' => sub {
"Hello There!"
};
get '/hello/:name' => sub {
my $params = shift;
"Hey ".$params->{name}.", how are you?";
};
Dancer->dance;
Je lance cet objet numérique étrange …
$ perl bin/mawebapp.pl == Entering the dance floor ... >> Listening on 0.0.0.0:8080
… Puis je joue avec
$ curl http://localhost:8080/ Hello There! $ curl http://localhost:8080/hello/YouFreak Hey YouFreak, how are you?
Merci oz !
Bientôt disponible sur github pour ceux qui veulent jouer avec moi c’est ici.
UPDATE 23 Juillet
Quelques corrections dans ce billet sur les exemple de code, pour un détail plus complet sur ce framework, je vous invite à lire le README ou à regarder l’application d’exemple fournie avec le source.
Tu n’arrêtes jamais dis donc ;)
Ca pourrait devenir une brique à pluguer sur Coat::persistent non ?
Je vais regarder ce que ca donne et pourquoi pas si je le peux te donner un coup de main. M’enfin, il faudra d’abord que j’améliore ma façon de coder.
A bientot
Une brique à Coat::Persistent pas vraiment, puisque C::P est un ORM, donc une interface sur une base de données, et Dancer un “application server” qui permet de créer une application web.
Par contre les deux pourraient très bien être utilisés ensemble au sein d’une meme appli.
Hello
Je me suis mal exprimé mais c’est bien l’idée que j’avais en tête quand je parlais de brique à associer à Coat::persistent.
Hello, ça me plaît bien ce mini framework :-)
Faudrait mettre à jour mawebapp.pl dans le post, qui serait maintenant:
my $params = shift;
“Hey “.$params{name}.”, how are you?”;
@Kai: voilà qui est fait, merci ;)
Pour ce qui est de la transmission des paramètres, j’expérimente une autre voie qui permet de ne pas déclarer $params dans les actions :
get '/hello/:name' => sub { "Hey ".params->{name}.", how are you?"; };Le code est dans la branche
shared-params. Je suis preneur de vos avis la dessus.Je pense qu’on doit perdre un peu en perfs, car au lieu d’accèder une variable ($params) on accède une fonction (params). Mais coté lisibilité des actions c’est mieux, et ça va dans l’idée “minimal-effort” … à voir.
oui c’est sympa de pas devoir declarer params dans chaque route handler
ca me parait pas un pb au niveau perfs, un appel de fonction en plus par invocation d’URL…
mais ca serait peut-etre encore mieux et plus simple d’emploi si c’etait une variable normale (hash ou reference de hash) instanciee magiquement dans le route handler, comme c’est le cas on dirait avec Sinatra http://www.sinatrarb.com/intro.html
cela dit je sais pas si c’est facile a faire, j’ai pas encore regarde le code
@Kai : j’ai commencé par regarder si on pouvait faire comme Sinatra et proposer une variable $params pré-initialisée dans les route handlers, mais comme Dancer force le mode strict (et j’y tiens ;) on est obligé de passer par une variable globale déclarée par Dancer.
En partant dans cette optique là, la seule methode que j’ai trouvée pour que les params soient correctement initialisés était de passer par un appel de fonction (params() en l’occurence) ; la variable globale $params restant désespéremment undef. D’ou le module Dancer::SharedData, je te laisse regarder le code pour les détails.
J’ai peut être raté un truc cela dit. Je suis preneur de patch si vous avec une autre approche ;-)
Bien, l’état actuel de la branche master me semble prêt pour une première release CPAN (avec notamment le support des vues, layout et before_filters).
Si vous avez un peu de temps, je suis preneur de tests :)