La puissance de l'intégration de rack dans rails 3

Rack est une interface entre votre serveur web et votre application basé sur le standard CGI mais sans ses caractéristiques globales (variables d'environnement et sortie standard).

Dans Rails 2.3

• ActionController::Dispatcher.new est l'application rack de base
• Le parseur de paramètres (ActionController::ParamsParser)est implémenté en tant que middleware
• Le routeur est une application rack qui dispatche vers les contrôleurs
• Chaque contrôleur est une application rack

cela a donc permis d'implémenter la notion de metal, des applications rack tournant autour de Ruby.

Mais ne nous attardons pas sur les choses qui sont vouées à disparaitre et passons plutôt directement à ce qui est intéressant : les nouveautés apportées par l'implémentation de Rack dans Rails 3.

Dans Rails 3

Vous l'avez déjà vu, Rails 3 implémente le concept d'application. Chaque application est un objet contenant un routeur et des paramètres et configuration ... Mais avant tout une application Rack !

Par conséquent les 10 lignes de code suivantes sont une application Rails 3 qui fonctionne. Dans un fichier nommé config.ru, placez :

require "action_controller/railtie"
 
class FooController < ActionController::Base
  def bar
    self.response_body = "Hello World !"
  end
end
 
class MyApp < Rails::Application
   config.session_store :disabled
 
   routes.draw do
     root :to => "foo#bar"
  end
end
 
run MyApp

Lancez l'application : rackup -p 4000. Rendez-vous sur localhost:4000 et vous verrez un bel "Hello World". Vos applications les plus simples n'ont plus rien à envier aux applications Sinatra.

Nous avons vu plus haut que Rails 2.3 commençait déjà à être conçu autour de middlewares rack. Dans cette nouvelle branche, cette intégration est encore plus flagrante. En effet Rails 3 inclue les fonctionnalités suivantes chacune dans un middleware différent :

• Un middleware exécutant les preparation callbacks
• Un middleware pour lire et écrire les cookies
• Un middleware qui nettoie les flash déjà affichés
• Un middleware qui gère les requêtes HEAD
• Un middleware vérifiant les IP spoofing
• Un middleware servant à rendre les fichiers statiques
• Un middleware de gestion des exceptions de bas niveau
• Un middleware pour les divers stockages en session
• Un middleware pour synchroniser les requêtes non thread-safe Dépends de Rack, pas de rails
• Un middleware pour mesurer le temps d'exécution d'une requête Dépends de Rack, pas de rails
• Un middleware permettant d'implémenter la sémantique de Send-file dans les divers serveurs Dépends de Rack, pas de rails
• Un middleware permettant de détecter les requêtes PUT et DELETE transmises en POST Dépends de Rack, pas de rails

Bien évidemment vous pouvez dans votre application ajouter, réordonner ou supprimer des middlewares.

Le routeur

Le routeur de Rails 3 a également été réécrit afin d'être mieux implémenté dans Rack. C'est Rack::Mount. Celui-ci reconnait des URL et les dispatche vers n'importe quelle application, même si elles ne sont pas rails. Il est ainsi tout à fait possible de faire la chose suivante

Rails.application.routes.draw do
  match "/blog" => BlogApplication
end

Vous n'avez plus qu'à écrire votre application de blog et elle sera intégrable dans votre application principale sous l'url /blog. Vous pouvez ainsi beaucoup plus aisément diviser votre application en de multiples modules, rendant chaque brique plus légère et donc plus aisée à développer.

Actions

Comme dit plus haut, chaque contrôleur est lui même une application Rack. Cela va même plus loin que cela puisque chaque action est en elle même une application rack ! Que vous pouvez exécuter indépendamment de l'application rails en elle même.

Cela se fait grâce à

MyController.action :index

Supposons par exemple un contrôleur Posts et une action show que vous souhaitez exécuter. Le fichier config.ru suivant sera exécuté sans problème avec rack.

class PostsController < ActionController::Base
  append_view_path "/path/to/views"
 
  def show
    render
  end
end
 
run ArticlesController.action(:show)

Votre rendu et tous vos callbacks seront bien évidemment exécutés. En fait, en interne, c'est grosso modo ce que rails lui même fait.

Dans les tests

L'utilité de ceci est une plus grande facilité d'exécution des tests. Dans rails 2.3, si votre application dépends beaucoup de middlewares, ceux-ci seront assez difficile à tester dans vos tests fonctionnels car ils ne seront pas exécutés. C'est notamment le cas si vous utilisez devise. La solution trouvée est de mocker les fonctions implémentées par le middleware.

Avec Rack::Test, vous pouvez fortement simplifier cela. Reprenons notre méthode show précédente et testons la.

Tout d'abord en instanciant l'application en elle même.

class TestApplication < Test::Unit::TestCase
  include Rack::Test::Methods
 
  def app
    MyApplication
  end
 
  def test_get
    get "/posts/1"
    assert_equal "Hello world !", last_response.body
  end
end

Et puis comme on peut ne faire que un appel à l'action, on se prive pas

class TestPosts < Test::Unit::TestCase
  include Rack::Test::Methods
 
  def app
    PostsController.action(:show)
  end
 
  def test_get
    get "/posts/1"
    assert_equal "Hello world !", last_response.body
  end
end

In fine

Si Rails 2.3 a commencé l'implémentation de Rack, Rails 3 plonge à plein nez dedans, s'intégrant pleinement avec l'application. Cela permet de rendre votre application beaucoup plus modulaire et puissante.

Nous avons vu ici une partie des nouvelles fonctionnalités du routeur. Mais ce n'est pas tout à ce niveau ! Attendez vous à d'autres :)