Rails 3.1 ne devrait plus tarder à sortir en version stable. Il apporte avec lui un lot conséquent de nouveautés. Celles qui font le plus d’émule sont certainement l’intégration par défaut de SCSS et CoffeeScript, l’introduction de Sprockets ou le remplacement de Prototype / Scriptaculous parJQuery comme librairie javascript par défaut.
Il faut savoir que tous ces choix par défaut sont modifiables ou désactivable donc pas d’inquiétude. Si vous préférez Prototype et que vous ne voulais pas faire de CoffeeScript ou de SCSS, aucun problème.
Je vais essayer de faire un tour rapide, mais certainement pas exhaustif, des nouveautés qui ont le plus retenues mon attention.
C’est très certainement l’une des nouveautés dont on parle le plus pour la sortie de Rails 3.1. Le système d’«asset pipeline» est basé sur la librairie Sprockets 2.0. Sprockets permet d’organiser correctement ses fichiers CSS et JavaScript y compris pour les plugins et engines. Sprockets intègre tout un tas de bonnes idées qui vont vous aider à mieux organiser vos fichier.
Ces fichiers javascript seront servis de manière optimale en production en un unique fichier ce qui permet d’économiser des requêtes et donc d’optimiser le temps de réponse. Sprockets est capable de travailler avec du JavaScript / CSS mais aussi avec CoffeeScript / SCSS que nous verrons plus en détail dans la suite.
Uglifier a également été ajouté pour compresser, minifier et obfusquer le fichier produit.
Il est même possible d’ajouter une couche erb (projects.css.scss.erb) pour interpréter du code Ruby générant du contenu dans le fichier CSS final.
Tout projet créé en Rails 3.1 tirera parti par défaut de SCSS qui permet de faciliter l’organisation de vos feuilles de style. C’est une extension de CSS3 qui ajoute la possibilité d’utiliser des règles imbriquées, des variables, des mixins, des filtres de couleur, … Vous pouvez en apprendre plus sur la page de tutoriel.
CoffeeScript sera également inclus par défaut et vous permettra de bénéficier des avantages de cette librairie. C’est un meta-langage qui se compile en javascript. CoffeeScript reste du vrai javascript mais saupoudré de sucres syntaxiques qui vous facilitent l’accès à l’écriture de fonctions, de classes, la manipulation d’objets ou des tableaux. Vous découvrirez que comme en Ruby on peut utiliser les if, unless de manière post-fixée. Il y a beaucoup trop de choses à dire pour en parler dans cet article mais prenez le temps de lire ceci en testant les exemples et aussi de jeter un œil à ce screencast.
Ces fichiers qui étaient avant relégués au répertoire “public” ont maintenant une vraie place dans l’application. Ces fichiers sont maintenant dans le répertoire “app/assets”. On y trouvera un répertoire “javascripts” et un autre “stylesheets”. Un scaffold créera un fichier “js.coffee” et “css.scss” au nom de votre contrôleur. Les CSS et JS sont donc maintenant considérés comme du vrai code applicatif et ont donc droit à une attention particulière.
Je ne vous garanti pas que vous adhérerez forcément aux nouvelles conventions mais elles méritent largement d’être essayées. Vous en serez peut-être totalement fan comme beaucoup après y avoir goûté.
Il est maintenant possible depuis un controller dans Rails de décider d’envoyer les en-têtes d’une réponse au client avant même d’avoir fini de générer le contenu de cette réponse. Comme vous l’imaginez, ceci peut considérablement améliorer les temps de réponse puisqu’il devient possible pour le client (un navigateur par exemple) de télécharger les feuilles de style et les javascripts alors que le corps de la réponse n’est même pas encore généré.
Pour utiliser cette possibilité, votre serveur doit supporter cette fonctionnalité. Pour l’heure le couple nginx / unicorn sont tout à fait capables de faire ça.
Je vous conseille ce screencast qui vous en apprendra un peu plus sur l’utilisation du streaming HTTP dans Rails 3.1.
Vous y apprendrez que cette méthode a des revers qui peuvent être bloquants dans certaines situations et c’est pourquoi le streaming n’est pas activé par défaut.
Désormais Rails utilisera jQuery par défaut. Revenir à Prototype revient à modifier une ligne dans le Gemfile. Il est d’ailleurs possible de choisir son framework à la création du projet.
Il s’agit là je pense d’une affaire de goûts, voir de besoins pour le projet. Libre à vous de choisir le framework que vous préférez.
Les migrations comme vous les connaissiez jusqu’à maintenant vont être simplifiées. Vous n’aurez plus un self.up et self.down mais un unique change qui sera capable de faire les opérations dans les deux sens. Du moins, dans la plupart des cas. Pour certains cas particuliers, vous devrez recourir à l’ancienne méthode.
Simple mais super pratique.
L’Identity Map ne semble pas encore activé par défaut, il présente toutefois une caractéristique très intéressante. Lorsque qu’un même enregistrement est récupéré plusieurs fois dans une requête, toutes ses références pointent sur un seul et même objet. Avant Rails 3.1, récupérer deux fois l’objet User ayant pour id 1 avait pour effet de créer 2 objets ayant certes les mêmes caractéristiques mais pourtant différents puisque n’ayant pas le même object_id. Depuis Rails 3.1, il est possible de faire en sorte que ces références pointent toutes vers le même objet ce qui laisse présager de meilleures performances et une meilleure gestion de la mémoire.
Rack::Cache va avantageusement remplacer le page caching. Rack::Cache est basé sur des standards et permet de mettre en place du cache conditionnel (fraicheur du contenu / date d’expiration).
force_ssl fait son apparition en simplifiant encore les méthodes de forçage du passage en mode SSL. Ce forçage peut être appliqué à l’application toute entière ou uniquement à certains contrôleurs.
les méthodes attr_accessible et att_protected acceptent désormais les rôles, on peut donc facilement mettre des filtres sur des attributs en fonction du rôle de l’utilisateur :
attr_accessible :foo, :as => :admin
Une implémentation très simple de chiffrage de mot-de-passe. Concernant cette fonctionnalité, je vous recommande ce screencast qui vous donnera les détails d’utilisation.
J’en rêvais depuis des années et c’est fait ! Ouvrez une console Rails, faites un find sur l’un de vos modèles et la requête sera loguée dans la console. Plus besoin de modifier son .irbrc ou de charger un gem dédié. Rien d’énorme mais super pratique au quotidien.
Plus besoin de se rappeler comment s’appelle l’option pour intégrer le multipart (upload de fichier), ni même de se soucier si le formulaire devra gérer de l’envoi de fichier. Les helpers s’en occupent maintenant pour nous et ajoutent automatiquement l’option multipart dès lors qu’elle est nécessaire au bon fonctionnement du formulaire. Dès que vous utiliserez un file_field, le formulaire sera automatiquement en multipart.
Pour avoir une vision exhaustive de tous les changements accompagnants cette nouvelle version de Rails, je vous invite vivement à parcourir le changelog qui vous dévoilera toutes les nouveautés et corrections.
Cette version risque de bouleverser les habitudes de développement pour certains. Ils auront à apprivoiser toutes ces nouvelles librairies inclues par défaut s’ils souhaitent développer “The Rails Way”. De plus, la courbe d’apprentissage risque d’être un peu plus corsée pour les nouveaux arrivants qui auront encore de nouveaux concepts et conventions à apprendre.
Il reste indéniable que la majorité des nouveautés intégrées reflètent largement les préférences, habitudes et bonnes pratiques de la communauté. Ces nouveautés prouvent que Rails continue d’être un framework à la pointe des technologies, des bonnes pratiques du moment et qui affirme ses opinions.
Apprendre à découvrir ces nouveautés, les exploiter au moins pendant un temps est la meilleure façon de se faire une idée. Faites un essai avec la nouvelle stack de Rails 3.1, vous y découvrirez peut-être vos nouveaux outils favoris. Si ce n’est pas le cas, tout est débrayable ou interchangeable.
L’équipe Synbioz.
Libres d’être ensemble.