L’un des points forts de Play! Framework c’est sa productivité. Lorsque vous modifiez une page web ou une classe Java, il suffit de recharger la page Web pour voir votre modification. Ceci vous évite, lorsque vous êtes en mode « dev », de perdre du temps à compiler et déployer votre application. Certes, il existe des outils comme JRebel, mais qui ne savent pas cependant répondre à une autre caractéristique de Play! Framework : il n’y a pas d’état. Chaque appel des méthodes d’un controller est indépendant. Vous ne verrez jamais une méthode prendre en argument une classe User par exemple (updated) le framework ne stocke pas d’entités, il est possible de passer un objet à une méthode, c’est une astuce de Play! pour dé-sérialiser les arguments HTTP d’un appel. En règle générale, vous verrez plutôt une méthode acceptant un userId. Vous devrez implémenter le rechargement de l’entité de la base ou d’un cache. Cela peut sembler curieux, lorsque l’on est habitué aux architectures avec session HTTP. Pourtant c’est de cette façon que fonctionne les sites à fort trafic. C’est aussi l’approche de PHP par exemple. Bref d’un framework Web.
Je travaille avec Git depuis quelques semaines. En quelques mots, Git est un gestionnaire de code source distribué, extrêmement rapide. Ce logiciel open-source a été initié par Linus Torvalds, afin de remplacer SVN sur le développement du noyau Linux. Avec Mercurial ou Bazaar, il fait partie de la famille des DVCS dont le Paris JUG a parlé en mai dernier.
Le concept de DVCS est vraiment le truc que vous devez apprendre rapidement. Je vous conseille de lire le Git Community Book pour commencer. Vous pouvez très bien utiliser Git en local, même avec une équipe qui travaille avec SVN. Je n’ai pas encore testé, mais il semble que cette approche permet de travailler encore plus efficacement. Git s’attache à suivre les modifications sur le contenu du fichier, plus sur une structure en répertoire et en fichier comme SVN. Il est donc capable de comprendre que « c’est le même contenu » même lorsque vous déplacez et changez souvent vos noms de fichiers. Au delà de ce concept, il est vraiment très puissant, et pas si compliqué à apprendre. Je le conseille aux équipes distribuées, ou à ceux qui ont un rythme de commit différent du reste de l’équipe… ce qui est le cas de tout le monde.
Alors pourquoi Play! et Git me dîtes vous ?
Et bien je découvre des fonctionnalités assez magique. Un peu lorsque tu découvres le combo bas, bas-droit, droit et bouton B pour envoyer une boule de feu avec Riu par exemple.
J’ai commencé un projet appelé GeekEvent sur GitHub, afin de préparer quelque chose de sympa pour le prochain Paris JUG. Pour coder ma partie « rssFeed » dans cette application, j’ai créé une branche Git, je l’ai implémenté, et pour l’instant je ne l’ai pas encore mergé dans la branche principale. Grâce à Git, je peux passer d’une branche à l’autre et là où c’est génial, c’est que lorsque je change de branche, et que Git me remet les fichiers de chaque branche, je n’ai qu’à recharger ma page dans mon navigateur pour voir le résultat !!!
Comme je n’ai pas de session au sens « Servlet » du terme, je peux même tester des fonctions de l’application, sans devoir remplir mon petit panier avec ma réservation d’Hôtel. Et comme à cet instant précis cher lecteur, je sais que tu n’as rien compris, j’ai fait une petite vidéo.
Voir la vidéo de Play! Framework et Git en action
Rendez-vous le mardi 12 octobre pour voir encore d’autres recettes avec Play! Framework pour le Paris JUG.
Rendez-vous le lundi 18 octobre pour venir à la conférence Soft Shake à Genève, où je présenterai Play! Framework.
0 no like
Merci Nicolas,
Tu m’as convaincu de tester Play 🙂 maintenant c’est GIT. A cause de toi, j’avance pas sur mes autres projets 🙁
Merci tout de même !
– Linus Torvalds pas Torvald.
– Use alias Luke! Tu tapes encore checkout ? 🙂
Et moi qui n’ai toujours pas pu me mettre à Play! je suis encore plus impatient, merci pour cet article!
> initié par Linus Torvald, afin de remplacer SVN sur le développement du noyau Linux
petite précision pour dire qu’avant git l’équipe du noyau linux utilisait déjà un DVCS, en l’occurence BitKeeper. Je le sais parce que j’ai fait quelques recherches dernièrement pour mon dernier billet 🙂
> C’est aussi l’approche de PHP par exemple.
Pas certain que ce soit vraiment l’approche de PHP. L’approche de certaines applications utilisant PHP oui mais du développement PHP utilisant les sessions c’est vachement courant…
Et puis je me réjouis de la présentation de Play! à Soft-Shake! J’espère juste que la session n’entrera pas en conflit avec d’autres sessions qui m’intéressent.
Je ne suis pas encore convaincu pas play! (A vrai dire je n’ai vraiment pas regardé), mais il est sûr que git apporte une énorme souplaisse à la gestion des sources.
« Vous ne verrez jamais une méthode prendre en argument une classe User par exemple ». A la lecture de la doc, c’est maintenant possible (cela l’a toujours été ?).
public static void create(Client client ) { client.save(); show(client); }@Emmanuel : en effet je me suis mal exprimé. Je confirme ce que j’ai dis : il n’est pas possible de faire passer un objet complet à une méthode.
Le cas particulier est celui que vous avez dans une méthode de création d’une entité. Dans le code que vous donnez, la méthode create serait l’action appelée d’un formulaire pour créer un Client. Play! est alors capable de désérialiser les parametres HTTP et de vous reconstituer une instance de Client, qu’il ne vous reste plus qu’à sauvegarder. Comprenez donc qu’ici il ne s’agit que d’un objet local créé à partir de la requête HTTP. La page web associée aurait l’ensemble des attributs de Client sous la forme de paramètres HTTP classique. Une astuce de binding/unmarshalling donc.
Hello Nicolas,
Article intéressant, merci.
Dans cette phrase : Git s’attache à suivre les modifications sur le contenu du fichier, plus sur une structure en répertoire et en fichier comme SVN
Il ne manquerait pas un mot, qui aurait son importance :
Git s’attache à suivre les modifications sur le contenu du fichier, plus QUE sur une structure en répertoire et en fichier comme SVN.
@++
A priori, personne n’a cliqué sur le lien pour ‘Play! Framework’. Sans le http:// devant le nom de domaine, les navigateurs (ou en tout cas, firefox) pensent qu’il s’agit d’un lien relatif….
Git & Play sont les deux choses que je veux absolument voir.. mais pour l’instant je n’en ai pas trouvé le temps.
Git, alors effectivement, DVCS cela dit tout, une fois que l’on comprends la signification et les avantages.
Et pour Play même si je suis jamais plus loin que la documentation j’ai lu qu’il y avait un support pour Scala et qu’il utilise groovy. Le fait de voir un framework qui combine des langages JVM est intéressant.
@Nicolas: on est bien d’accord qu’il s’agit d’une « aide » qui évite de devoir faire explicitement le binding. Et pour être précis cela fonctionne pour une création, mais aussi pour une mise à jour etc… à partir du moment où un id est fourni parmi les paramètres HTTP. (doc Play!, section JPA object binding)
@Bertrand : coquille corrigée, merci.
Note : il est possible que la vidéo ne marche pas car j’ai explosé mon quota ScreenCast. Je n’ai droit qu’à 2gb par jour. Essayez dans ce cas de revenir le lendemain pour la visualiser. Promis dès que j’ai un peu plus de sous, je prends un abonnement.