• comment organiser les modèles ;
• comment créer la table ;
• comment gérer le type du modèle avec un seul contrôleur.

Qu'est-ce que c'est ?

«Single Table Inheritence» (STI) (en français «Héritage de table unique») est un moyen de faire de l'héritage en n'utilisant qu'une seule table en base de données. Le tout est de savoir comment structurer ses modèles et le tour est joué !

Illustration par un exemple

Supposons que nous avons plusieurs types d'utilisateurs. Des administrateurs qui ont tous les droits et des éditeurs qui n'ont que des droits d'édition. Nous pouvons donc ici utiliser l'héritage pour nos modèles utilisateurs. Une classe mère User et deux classes filles Administrator et Editor.

Création des modèles

Comme tout héritage classique, il faut une classe par modèle.

# app/models/user.rb
class User < ActiveRecord::Base
end

# app/models/editor.rb
class Editor < User
end

# app/models/administrator.rb
class Administrator < User
end

Pour avoir une structure plus «propre», on peut mettre les fichiers editor.rb et administrator.rb dans un sous dossier /app/models/users/ et il faudrait alors suffixer les noms de classe des deux modèles par Users::.

Création de la table

Comme je l'ai dit plus haut, une seule table en base de données est nécessaire. Cette table doit contenir les champs des trois modèles. Tout ce qui correspond au modèle User, Editor et Administrator.

En plus de tous ces champs, il faut rajouter une colonne type qui permettra de savoir de quel type est la ressource en question.

# db/migrate/124812048_create_user.rb
class CreateUser < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :username
      t.string :password
      ...
      t.string :type
      t.timestamps
    end
  end
  def self.down
    drop_table :users
  end
end

Ajout des routes

Pour ce qui est des routes, il suffit de les déclarer comme des ressources. Si vous voulez n'utiliser qu'un seul contrôleur vous pouvez faire comme ceci :

# config/routes.rb
resources :users,          :controller => 'user', :type => User.name
resources :editors,        :controller => 'user', :type => Editor.name
resources :administrators, :controller => 'user', :type => Administrator.name

En rajoutant un couple clé/valeur après la définition de la ressource, on précise au routeur de passer un paramètre qui correspond à la clé avec sa valeur associée. Ici, on définit le paramètre :type avec le nom de la ressource.

De cette façon quand vous accèderez à l'url /editors/new la requête sera redirigé vers le contrôleur UsersController.

Côté contrôleur

Voyons maintenant comment différencier les trois types d'utilisateurs côté contrôleur.

Le post d'Alan Peabody sur Stack Overflow propose une solution intéressante pour gérer le type de modèle dans le contrôleur. Il suggère d'ajouter une méthode privée qui permettra d'accéder à la classe du type de modèle concerné.

# app/controllers/users_controller.rb
private
def user_type
  params[:type].constantize
end

Ainsi vous n'aurez pas à vous soucier de la gestion du type dans vos autres méthodes.

# app/controllers/users_controller.rb
def index
  @users = user_type.all
  # …
end
def new
  @user = user_type.new
  # …
end
def create
  @user = user_type.new(params)
  # …
end

N'hésitez pas à proposer d'autres solutions ou à me reprendre si besoin !

Références

• Rails Single Table Inheritance de TechKnow.
• Single Table Inheritance in Rails de Alex Reisner
• Single Table Inheritance de Martin Fowler
• Réponse de fl00r – Stack Overflow
• Réponse d'Alan Peabody – Stack Overflow

• Avoir compris le fonctionnement des routes.
• Avoir vu le routage de ressources.

Nous avons vu comment définir des relations d'associations entre différents modèles, ainsi que la façon de définir des routes pour des ressources. Passons maintenant à la gestion des ressources imbriquées.

Présentation du problème

Reprenons l'exemple de l'article sur les associations many-to-many pour illustrer le problème. Nous avons un modèle Article et un modèle Tag. Un article peut avoir plusieurs tags et un tag appartient à plusieurs articles. Ces modèles sont les ressources que nous allons manipuler et sont donc liés par une relation many-to-many.

Le problème est que nous voulons représenter cette relation dans les URLs, c'est-à-dire par exemple, accéder à la liste de tous les tags d'un article par l'url : http://monsite.fr/articles/id_de_l_article/tags.

Routes

Afin de représenter cette imbrication de ressources au niveau des URLs, on définit les routes comme ceci :

# config/routes.rb
resources :articles do
  resources :tags
end

Cette déclaration permet de définir les routes pour les Articles mais aussi pour les Tags.

CRUD, méthodes HTTP et actions

Voyons de plus près l'ensemble des routes générées :

Il est important de noter que les URLs permettant d'accéder aux tags requièrent l'id d'un article, en effet, nous allons devoir fournir cet id à chaque path helper. Voyons justement les chemins et URLs qui sont générés à partir de cette déclaration de route.

Chemins et URLs générés

Contrôleur

Après avoir modifié les routes, il est souvent nécessaire d'apporter des modifications au code existant pour pouvoir faire fonctionner l'application avec les ressources imbriquées. Par exemple, si vous avez générés vos modèles à l'aide de scaffold et que l'ensemble des vues et contrôleurs existent déjà il faut les modifier.

Ajout d'une référence

Tout d'abord, nos tags sont dépendants d'un article, il faut donc définir cet article dans le contrôleur. Il est possible pour cela de créer une variable faisant référence à l'article auquel appartient le tag en ajoutant ce morceau de code au début de chaque méthode où la référence est nécessaire :

@article = Article.find(params[:article_id])

Le params[:article_id] permet de récupérer l'id de l'article qui est passé dans l'URL.

Pour éviter la duplication de cette ligne de code, on peut créer une méthode qui définie cette variable. Pour que cette méthode soit exécutée avant les autres, on définit un before_filter, comme ceci :

# app/controllers/tags_controller.rb
class TagsController < ApplicationController
  before_filter :find_article  
  def index
    ...
  end
  ...
  def destroy
    ...
  end
  private
  def find_article
    @article = Article.find(params[:article_id])
  end
end

Pour en savoir plus sur les filtres en Ruby On Rails

Modification des path helpers

Maintenant que la référence à l'article auquel appartient le tag est définie, il faut modifier les redirect_to dans les méthodes create, update et destroy comme ceci :

# app/controllers/tags_controller.rb
class TagsController < ApplicationController      
  …
  def create
    …
    format.html { redirect_to [@article, @tag] }
    …
  end
  def update
    …
    format.html { redirect_to [@article, @tag] }
    …
  end
  def destroy
    …
    format.html { redirect_to article_tags_url }
    …
  end
end

Il faut noter qu'en Ruby On Rails [@article, @tag] est équivalent à article_tag_path(@article, @tag)

Vues

Ensuite il est nécessaire d'adapter l'ensemble des vues précédemment générées avec les scaffolds pour que ça fonctionne. Il faut modifier l'ensemble des paths existant en rajoutant les variables @article et @tag comme par exemple pour la vue index de tags :

<h1>Listing tags</h1>
<table>
  <tr>
    <th>Name</th>
    <th>Article</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>
<% @tags.each do |tag| %>
  <tr>
    <td><%= tag.name %></td>
    <td><%= tag.article_id %></td>
    <td><%= link_to 'Show', article_tag_path(@article, tag) %></td>
    <td><%= link_to 'Edit', edit_article_tag_path(@article, tag) %></td>
    <td><%= link_to 'Destroy', article_tag_path(@article, tag), :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>
<br />
<%= link_to 'New Tag', new_article_tag_path %>

Évitez d'imbriquer trop de ressources. Essayez de vous limiter à une imbrication, cela permet d'avoir des URLs plus lisibles et des path helper moins long et moins contraignant à écrire.

Par exemple si vous avez trois ressources Post, Comment et Favorite, vous pouvez diviser l'imbrication :
posts/:post_id/comments/:comment_id/favorites
en deux imbrications :
posts/:post_id/comments/:comment_id
comments/:comment_id/favorites/:favorite_id

Pour cela il faut écrire les routes en deux parties comme ceci :

# config/routes.rb
resources :posts do
  resources :comments
end
resources :comments do
  resources :favorites
end

Ressources

• Guides Rails - Routes
• Rails Best Practices - Needless deep nesting
• Filtres en Ruby On Rails

• connaître l'héritage ;
• avoir déjà vu les différentes associations (One-to-Many, Many-to-Many, Many-to-Many avancées).

Qu'est-ce que c'est ?

L'association polymorphique est une association qui permet à un modèle d'appartenir à plusieurs autres modèles. Il ne dépend donc pas d'un unique modèle. Par exemple, un modèle Comment peut appartenir à des Articles, mais aussi à des Events. De cette façon, vous n'avez pas besoin de dupliquer des modèles ayant des informations similaires.

Un exemple concret

Illustrons le problème par un exemple. Supposons que nous avons trois modèles : Article, Event et Photo. Le but est de créer un unique modèle Comment pour nos trois types de ressources.

Voilà un schéma représentatif de ce que l'on veut obtenir :

Création du modèle

Comme toujours, des conventions sont à respecter pour que tout se passe comme prévu. Le modèle Comment n'étant plus lié à un modèle spécifique, il faut lui spécifier un champ qui réfèrera à l'ID de la ressource auquel il appartient ainsi que le type de ce dernier. Voilà comment générer le modèle Comment 

$ rails g model Comment content:text commentable_id:integer commentable_type:string

Migration

Pour récapituler, il faut stoquer l'ID de l'objet auquel le commentaire appartient et le type de ce dernier. Côté migration, deux façons d'écrire :

# db/migrate/201101249412_create_comments.rb
class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.string :content
      t.integer :commentable_id
      t.string  :commentable_type
      t.timestamps
    end
  end
end

Ou :

# db/migrate/201101249412_create_comments.rb
class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.string :content
      t.integer :commentable, :polymorphic => true
      t.timestamps
    end
  end
end

Associations dans les modèles

Il faut maintenant déclarer dans les modèles concernés les associations de la façon suivante :

# app/models/comment.rb
class Comment < ActiveRecord::Base
  belongs_to :commentable, :polymorphic => true
  ...
# app/models/event.rb
class Event < ActiveRecord::Base
  has_many :comments, :as => :commentable
  ...
# app/models/photo.rb
class Photo < ActiveRecord::Base
  has_many :comments, :as => :commentable
  ...
# app/models/article.rb
class Article < ActiveRecord::Base
  has_many :comments, :as => :commentable
  ...

Création d'un commentaire

Si on veut maintenant créer un commentaire et l'associer à un article, on peut simplement faire 

@article.comments.create(:content => 'Mon contenu')

Aller plus loin

Ressources imbriquées

Si on veut généraliser et que l'on veut accéder par exemple à tous les commentaires d'un article par l'URL /articles/1/comments il faut utiliser les ressources imbriquées et pour cela modifier les routes.

# config/routes.rb
resources :model_name do
  resources :comments
end

En faisant ça pour chaque modèle, la route /model/1/comments redirigera alors vers l'action index de CommentsController. Et c'est dans cette méthode qu'il faut, en fonction du type de la ressource, afficher les commentaires.

Récupérer la ressource

Ryan Bates nous propose dans son RailsCast une méthode pour récupérer la ressource concernée.

# app/controllers/comments_controller.rb
private
def find_commentable
  params.each do |name, value|
    # Regex correspondant à la forme model_id
    if name =~ /(.+)_id$/
      # $1 correspond au nom du modèle
      return $1.classify.constantize.find(value) 
    end
  end
  nil # Retourne nil si rien n'a été trouvé
end

La méthode ci-dessus parcours tous les paramètres envoyés par le client et cherche un paramètre se terminant par _id. Si nous étions à l'url /articles/1/comments, nous aurions par exemple article_id avec comme valeur 1.

Si la méthode trouve une correspondance dans les paramètres, elle appelle la méthode classify sur le nom du modèle. La méthode classify transforme les chaînes de caractère s'apparentant à des noms de tables en des chaînes de caractère pouvant correspondre à des noms de classe. Par exemple 

"egg_and_hams".classify # => "EggAndHam"
"posts".classify        # => "Post"

Puis, la méthode constantize est appelé pour essayer de trouver une constante correspondante. «Article» deviendra alors la constante correspondant à la classe Article.

Enfin, la méthode find est appelé pour récupérer l'objet en question.

Afficher et créer un commentaire

De cette façon, on peut maintenant afficher dans notre vue index de comments, tous les commentaires de l'objet concerné.

# app/controllers/comments_controller.rb
def index
  @commentable = find_commentable
  @comments    = @commentable.comments
end

Et dans la vue :

# app/views/comments/index.html.erb
<h1>Liste des commentaires</h1>
<ul id="comments">
  <% @comments.each do |comment| %>
    <li><%= comment.content %></li>
  <% end %>
</ul>
<h2>Nouveau commentaire</h2>
<% form_for [@commentable, Comment.new] do |form| %>
  <ol class="formList">
    <li>
      <%= form.label :content %>
      <%= form.text_area :content, :rows => 5 %>
    </li>
    <li><%= submit_tag "Add comment" %></li>
  </ol>
<% end %>

Et enfin, pour l'action create du contrôleur 

# app/controllers/comments_controller.rb
def create
  @commentable = find_commentable
  @comment = @commentable.comments.build(params[:comment])

Voilà pour ce qui est des associations polymorphiques !

Références

• Rails Casts de Ryan Bates ;
• ActiveRecord Association RailsGuides.

Rappel sur les ressources et sur REST

Notion de ressource

La notion de ressource est vague et donc de difficile à définir. Prenons la première définition explicite du terme ressource dans son sens le plus général donnée par Tim berners Lee  :

Une ressource peut être toute chose qui possède une identité. Des exemples familiers incluent un document électronique, une image, un service (par exemple "le bulletin météo d'aujourd'hui pour Los Angeles"), ou un ensemble d'autres ressources. Certaines ressources ne peuvent pas être "ramenées par le réseau" (network retrievable), par exemple les êtres humains, les entreprises, les livres d'une bibliothèque peuvent être aussi considérés comme des ressources.

Ce qu'il est important de comprendre c'est qu'une ressource est finalement n'importe quoi que l'on peut identifier de manière unique par une URI (Uniform Resource Identifier). Sur le web, cet identifiant unique est généralement une URL.

Même si cette notion paraît difficile à appréhender aux premiers abords, elle vous paraîtra plus claire une fois utilisée dans une application. Passons donc à la suite et à une approche de l'architecture REST.

Notion de REST

REST est un style architectural, une manière de construire une application pour le web. Les principes essentiels d'une architecture REST sont les suivants :

• Chaque ressource doit être identifiée de manière unique par une URI.
• Les méthodes HTTP GET, POST, PUT et DELETE suffisent pour accéder à et modifier une ressource.

Exemple d'application RESTful

Je pense qu'il n'y a pas plus parlant qu'un exemple pour comprendre ce qu'est l'architecture REST et ce qu'est une ressource.
Prenons donc l'exemple d'un blog contenant plusieurs articles. Ici, les ressources à manipuler sont les articles. Dans ce blog on peut ajouter, modifier, lire, et supprimer des articles. Chaque article a un identifiant unique, ici c'est son nom. Donc, pour que l'application respecte l'architecture REST elle doit permettre les actions suivantes :

• Lire un article - on effectue une requête de type GET sur http://monblog.fr/articles/nom-de-mon-article. Le nom de l'article étant son identifiant unique.
• Écrire un article - on effectue une requête de type POST sur http://monblog.fr/articles/. Le contenu du message POST représentant le contenu du nouvel article à créer.
• Modifier un article - on effectue une requête de type PUT sur http://monblog.fr/articles/nom-de-mon-article. Le contenu du message PUT représentant le contenu modifié de l'article.
• Supprimer un article - on effectue une requête de type DELETE sur http://monblog.fr/articles/nom-de-mon-article.

Si vous avez besoin de plus d'informations au sujet de REST reportez vous à la section REST de l'article Avant de commencer avec Ruby On Rails

Les routes pour des ressources

CRUD, méthodes HTTP et actions

En Rails, le routage de ressources fournit une correspondance entre les verbes HTTP et les URLs avec les actions du contrôleur. Par convention, chaque action du contrôleur correspond à une opération CRUD (create, read, update, destroy) dans la base de données.

Prenons un exemple, supposons que nous avons un blog contenant des articles qui sont ici les ressources à manipuler. Voici comment définir les routes pour ce type de ressources :

# config/routes.rb
resources :articles

Cette seule règle permet de définir les routes pour les actions index, show, new, edit, create, update et destroy, qui sont les actions typiques que l'on doit pouvoir effectuer sur une ressource.

Nous obtenons les sept routes suivantes qui s'appliquent toutes au contrôleur articles_controller :

Il est important de savoir qu'il y a une priorité sur les règles. Les règles écrites au début du fichier sont prioritaires par rapport à celles écrites en dessous.

Chemins et URLs générés

Comme pour toutes les routes, le routage de ressources génère des chemins et des URLs. Voici un tableau récapitulatif de ces helpers et des actions vers lesquelles ils redirigent en fonction du verbe HTTP employé :

Comme tous les routes helpers, il y a aussi les URLs helpers qui sont générés. Pour s'en servir, il suffit de remplacer …_path par …_url. Par exemple, new_article_url.

Exemple d'utilisations

Le routage de ressource est utilisé par Rails lorsque l'on crée un scaffold. Rails génère les routes, le modèle, la table en base de données, les actions RESTful dans le contrôleur et les vues. Donc pour voir un bon exemple des path_heplers, il suffit de regarder dans les vues générées.

Par exemple, si on crée le scaffold suivant :

$ rails generate scaffold Article title:string content:text

On peut constater l'utilisation des path_helpers suivants :

# app/views/articles/index.html.erb
...
<%= link_to 'New Article', new_article_path %>
...

# app/views/articles/show.html.erb
...
# Ici @article est défini dans la méthode show du contrôleur articles_controller
<%= link_to 'Edit', edit_article_path(@article) %> |
<%= link_to 'Back', articles_path %>
...

# app/views/articles/show.html.erb
...
# Ici @article est défini dans la méthode edit du contrôleur articles_controller
<%= link_to 'Show', @article %> |
<%= link_to 'Back', articles_path %>
...

Pour le dernier exemple, on peut voir que le lien pour l'action show n'utilise pas le path_helper article_path(@article). Ceci est dû au fait que Rails comprend tout seul que lorsqu'on lui passe directement une instance de l'objet Article il doit utiliser le path_helper article_path et donc on fonction de la méthode HTTP utilisé il redirigera vers la bonne action du contrôleur. Ici c'est un lien donc c'est la méthode GET qui est utilisé et donc ce lien redirigera vers l'action show.

Définir plusieurs ressources

Le routeur Rails nous permet de définir plusieurs ressources en une seule ligne de la façon suivante :

resources :articles, :photos, :authors

Les routes pour une ressource unique

CRUD, méthodes HTTP et actions

Il peut arriver que l'on ait besoin de définir les routes pour une ressource unique à laquelle on aimerait accéder sans préciser une ID. Le routeur Rails nous permet de définir ce genre de route. Prenons un exemple pour voir l'ensemble des routes créées.

# config/routes.rb
resource :account

Faire attention, dans ce cas il n'y a pas de « s » au mot resource

Cette seule règle permet de définir les routes pour les actions show, new, edit, create, update et destroy du contrôleur accounts_controller. Voici un récapitulatif :

Chemins et URLs générés

Dans la ces d'une ressource unique, les path_helpers générés ne prennent pas de paramètre étant donné que la ressource à modifier est toujours la même. Voici un tableau récapitulatif de ces helpers et des actions vers lesquelles ils redirigent en fonction du verbe HTTP employé :

Ajouter des actions RESTful

Il arrive souvent que l'on ait besoin d'ajouter des routes à une ressource pour des actions autres que celles définies par défaut. Le routeur Rails nous permet de le faire très simplement, voyons comment.

Ajout d'une action sur la collection

Tout d'abord, il faut définir si cette action va agir sur l'ensemble des ressources ou seulement sur une seule. Prenons un exemple, supposons que l'on ait un contrôleur photos_controller et que l'on veuille ajouter la possiblité de faire une recherche sur les photos. Dans ce cas, l'action sera effectuée sur l'ensemble des ressources photos. Donc on défini les routes comme ceci :

resources :photos do
  get 'search', :on => :collection
end

Il est possible d'utiliser des symboles à la place des chaînes de caractères. Par exemple, on pourrait écrire :
get :search, :on => :collection

Ajout d'une action sur un membre

Supposons maintenant que l'on veuille effectuer une action sur une seule ressource, par exemple accéder à une previsualisation d'une photo. Dans ce cas on peux définir les routes comme ceci :

resources :photos do
  get 'preview', :on => :member 
end

Les routes helpers obtenus dans les deux cas précédents sont respectivement search_photos_path et preview_photo_path. Bien faire attention au « s » à la fin de photos que l'on met que lorsque l'action est sur la collection entière.

Si on a beaucoup d'actions à ajouter sur les membres ou sur la collection entière on peut également définir les routes comme ceci :

resources :photos do
  member do
    get 'preview'
    get 'buy'
  end
  collection do
    get 'search'
    get 'another_action'
  end
end

Il faut noter ici que l'on peut remplacer let mot get par les autres méthodes HTTP, par exemple post

Voilà les bases pour le routage de ressources en Rails, je publierai prochainement un article sur les ressources imbriquées. Si vous avez des questions ou améliorations à proposer n'hésitez pas à laissez un commentaire.

Références

• Guide Rails - Rails Routing from the Outside In

• mettre en place son environnement Ruby On Rails ;
• installer MySQL et PostgreSQL ;
• les bases de RVM.

L'environnement Ruby

Installer les outils développeurs

Le language Ruby est fourni avec les outils développeurs Mac OS X, donc pour avoir son environnement Ruby fonctionnel il suffit d'installer XCode. Si vous avez fait une mise à jour depuis Snow Leopard et que vous vous retrouvez avec un tas de bugs mystiques je vous conseille grandement de réinstaller XCode pour que les liens des librairies soient mis à jour. Voilà la commande à taper dans un terminal pour supprimer totalement XCode :

$ sudo /Developer/Library/uninstall-devtools –mode=all

Installer Rails

Et bien voilà, vous pouvez maintenant installer le framework Ruby On Rails.

$ gem install rails

Vous pouvez maintenant réinstaller XCode fraichement !

Installer MySQL (5.5)

Le plus simple reste de passer par l'image fournit sur le site de MySQL et d'installer tout ce qui se trouve à l'intérieur.

Pour ma part, j'ai pris la version 64bit : Mac OS X ver. 10.6 (x86, 64-bit), DMG Archive.

Pour savoir si vous êtes en 64 bits, lancez l'application Information Système, cliquez sur Logiciel et regardez si votre noyau est en 64bits.

Sinon, en ligne de commande :

$ sysctl hw |grep 64bit
> hw.cpu64bit_capable: 1 # Vous êtes en 64 bits
> hw.cpu64bit_capable: 0 # Vous n'êtes pas en 64 bits

Une fois l'installation faite, il faut penser à rajouter le chemin des binaires MySQL à votre PATH. Pour que votre PATH et vos librairies dynamiques soient bien à jour, rajouter les lignes qui suivent dans le fichier .profile qui se trouve à la racine de votre home. (Exemple: /Users/Nima/.profile ou ~/.profile).

# ~/.profile
export PATH="$PATH:/usr/local/mysql/bin"
export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/usr/local/mysql/lib"

Si le fichier n'existe pas, vous pouvez le créer en utilisant la commande touch.

$ touch ~/.profile

Sachez que vous pourrez lancer ou arrêter MySQL à partir de vos préférences système. Une icône de MySQL doit se trouver dans la partie «autre».

Installer PostgreSQL (9.1.1)

Installation de PostgreSQL

Encore une fois, le plus simple reste de passer par l'image fournit par PostgreSQL.

L'installation va vous demander de redémarrer. Faite le puis relancez l'image et l'installation. Pensez à bien spécifier un mot de passe pour l'utilisateur postgres.

Une fois l'installation faite, il faut créer un utilisateur.

Création d'un utilisateur

Voilà la commande à taper dans votre terminal pour créer un utilisateur. Ici le nom d'utilisateur sera admin. L'option --username permet de spécifier que cette action doit être éxécuter par l'utilisateur postgres et l'option --pwprompt force la demande d'un mot de passe.

$ createuser admin --superuser --pwprompt --username postgres
Enter password for new role: # password pour l'utilisateur admin
Enter it again:
Password: # celui que vous avez entré pendant l'installation de postgres

Installer RVM

RVM est un outil très utile si l'on veut utiliser des versions de Ruby différentes pour plusieurs projets ou si on veut séparer ses gems d'un projet à un autre. Pour l'installer, il suffit de faire ce qui est indiqué sur le site officiel, autrement dit, éxécuter ce qui suit dans un terminal.

$ bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

Puis, comme indiqué à la fin de l'installation, ajoutez ce qui suit dans votre .profile :

# ~/.profile
[[ -s "/Users/Nima/.rvm/scripts/rvm" ]] && source "/Users/Nima/.rvm/scripts/rvm"  # This loads RVM into a shell session.

Les Gem et les Gemsets

Il est possible que vous vous demandiez ce qu'est une Gem. Est bien c'est simple, comme l'indique la doc de RubyGems.org, une gem est une application Ruby sous forme de paquet ou de librairie. Par exemple, Rails est une gem.

Les gemsets sont des ensembles de gems et chaque ensemble est associé à un projet / environnement de travail spécifique.

Supposons que vous vouliez utiliser la version 1.9.2 de Ruby pour votre projet. Commencez par l'installer, comme ceci :

$ rvm install 1.9.2

Puis spécifiez à RVM que vous voulez utiliser cette version dans le terminal courant.

$ rvm use 1.9.2

Pour utiliser une version par défaut, rajouter l'option --default. Par exemple, rvm use --default 1.9.2.

Maintenant vous pouvez créer un Gemset et spécifier que vous voulez utiliser la version 1.9.2 pour votre projet.

$ rvm gemset create mon_projet
$ rvm use 1.9.2@mon_projet

A partir de là, toute les gems que vous allez installer seront installées dans le Gemset que vous venez de créer.

Pour éviter de devoir retaper rvm use 1.9.2@mon_projet vous pouvez vous faire des alias dans votre .profile.

# ~/.profile
alias mon_projet="rvm use 1.9.2@mon_projet; cd ~/Development/Rails/mon_projet"

De cette façon vous n'aurez qu'a taper une commande dans le terminal pour vous trouver dans bon dossier de travail et utiliser le bon Gemset.

Bundler

Bundler est un gestionnaire de dépendance pour gérer les Gems de votre projet. Donc au lieu d'installer toutes les dépendances de vos projet les unes après les autres, vous les listerez dans le Gemfile de votre application, et il ne suffira que d'une commande pour que tout s'installe correctement. Autant vous dire que c'est un outil quasi indispensable !

Cessons de discuter ! Voilà comment installer le gem Bundler...

$ gem install bundler

Et pour lancer l'installation des gems listées dans le fichier Gemset de votre application Rails, il suffit de se placer à la racine de votre application et de lancer la commande suivante :

$ bundle install

Donc suivant le système de gestion de base de données que vous voulez utiliser, il suffit de mettre une des deux lignes suivantes dans le fichier Gemfile puis d'éxécuter à nouveau la commande bundle install.

# Gemfile
gem 'pg'      # Pour PostgreSQL
gem 'mysql2'  # Pour MySQL

Voilà pour votre environnement Rails ! Vous devriez être «Up and running!» comme disent les anglais !

Si ça ne marche pas n'hésitez pas à nous laissez un commentaire, nous pourrons essayer de vous aider !

• Le fonctionnement du routeur Rails.
• Les utilisations de bases.

Comprendre le fonctionnement

Voici une schéma explicatif permettant de comprendre le rôle du routeur dans le fonctionnement d'une application Rails.

Le processus commence avec une requête faite à partir du navigateur. Cette requête est ensuite transmise au routeur Rails qui l'analyse et extrait les informations suivantes :

• le contrôleur à instancier ;
• l'action (correspondant à une méthode) à appeler dans ce contrôleur ;
• enfin, si il y en a, les paramètres à passer à cette méthode.

Lorsqu'il reçoit une URL correctement formattée, le routeur Rails instancie le contrôleur spécifié et appelle la méthode appropriée en lui passant les paramètres si besoin. Le contrôleur va donc effectuer les actions nécessaires et Rails renverra la vue correspondante. Cette vue sera ensuite renvoyée au navigateur. Cette explication est volontairement simplifiée mais elle montre l'importance du routeur Rails.

Par contre si le routeur Rails reçoit une URL mal formattée, il sera incapable d'effectuer les bonnes actions. Il est donc très important que le format de l'URL soit correct, c'est pourquoi le routeur Rails à également une deuxième fonction : nous aider à générer de bonnes URLs.

Donc pour synthétiser, le routeur Rails à deux fonctions principales :

• connecter des URLs au code, c'est à dire les interpreter, instancier le bon contrôleur et enfin appeler les bonnes actions ;
• générer des chemins et des URLs sans avoir besoin de les écrire «à la main» dans le code.

Le routeur Rails effectue ces deux fonctions en utilisant les règles de routage définies dans le fichier config/routes.rb. Voyons chacune de ces fonctions un peu plus en détail.

Connecter les URLs au code

Prenons un exemple, supposons que j'ai écris une fonction new dans le contrôleur articles_controller. J'aimerais que cette méthode soit éxecutée lorsque j'accède à l'URL suivante : www.monsite.fr/articles/new.

Pour cela, il suffit simplement de définir la règle suivante dans le fichier config/routes.rb :

# config/routes.rb
match "articles/new" => "articles#new"

Décorticons un peu cette règle. Tout d'abord on définit l'URL que notre routeur doit reconnaître avec la première partie de la règle : match "articles/new".

On note qu'il n'y a pas besoin de préciser le nom de domaine, ceci est dû au fait que notre routeur ce trouve dans notre application et que notre application est accessible via son nom de domaine.

Ensuite on précise quelle partie de code doit être éxécutée lorsque l'on pointe vers cette URL, avec la seconde partie de la règle => "articles#new". Ce qui se trouve à gauche du # correspond au contrôleur à instancier et ce qui se trouve à droite correspond à la méthode à appeler.

Rails nous permet également de définir la même règle plus simplement :

# config/routes.rb
get "articles/new"

Voilà un exemple de la première utilité du routeur Rails qui est de relier les URLs au code, passons maintenant à la seconde utilité de ce routeur.

Générer des chemins et des URLs

Un peu de théorie

Le routeur permet également de générer des routes helpers qui sont des méthodes qui renvoies une URL correctement formattée. En effet, si vous avez écrit la règle précedente dans votre fichier config/routes.rb et que vous tapez la commande suivante dans un terminal à la racine de votre application :

$ rake routes

vous obtiendrez ceci :

new_article GET /articles/new(.:format) {:controller => "articles", :action => "new"}

A partir de cette ligne on peut extraire les informations suivantes :

• Le prefixe du helper, qui est ici new_article
• La méthode HTTP utilisé, ici c'est GET.
• Le format de l'URL, ici c'est /articles/new(.:format).
• Le contrôleur qui sera appelé si on accède à cette URL
• Et enfin, l'action du contrôleur qui sera appelée.

A partir du préfixe, on obtient le nom des deux helpers générés à savoir new_article_path et new_article_url. La différence entre les deux est tout simplement que la version URL contient le nom de domaine et le port en plus du chemin. Par exemple :

• new_article_path redirige vers /articles/new(.:format)
• alors que new_article_url redirige vers http://www.monsite.fr/articles/new(.:format)

Dans l'exemple précédent, le numéro du port n'est pas indiqué car c'est le port HTTP par défaut à savoir le port 80.

Utilisation de ces helpers

Les helpers générés par le routeur Rails peuvent s'utiliser dans la vue et rendent le code plus facile à lire et plus fiable puisque qu'on est sûr que l'URL sera bien formatée. Par exemple pour faire un lien interne qui redirige vers www.monsite.fr/articles/new on peut tout simplement faire comme ça :

<%= link_to "Créer un nouvel article", new_article_path %>

Voilà pour ce qui est des bases des routes en Rails. Je publierai d'autres articles pour détailler les différentes manières de définir les règles dans le fichier routes.rb. Si vous avez des questions ou des améliorations à proposer n'hésitez pas à laisser un commentaire.

Références

• Beginners Tutorial: Routing in Rails 2.0
• Guide Rails : Rails Routing from the Outside In

• avoir vu les associations Many-to-Many simples.

Présentation du problème

Avec les relations Many-to-Many nous avons déjà réussi à résoudre un certain nombre de problèmes pour ce qui était des relations entre deux objets. Allons encore plus loin. Supposons que vous vouliez stocker des informations supplémentaires et relatives à votre relation. Des propriétés propres à la relation et non aux objets liés.

Un exemple concret

Illustrons le problème. Supposons que nous avons deux modèles : Doctor et Patient.

Un docteur a plusieurs patients et un patient peut avoir plusieurs docteurs. Pour gérer les rendez-vous, nous avons besoin de savoir la date du prochain rendez-vous entre le docteur D et le patient P.

Dans la théorie

Il nous faut une table de jointure entre ces modèles avec la référence du docteur, la référence du patient et des champs qui décrivent le rendez-vous. Cette approche est très similaire à une relation Many-to-Many classique à la différence que cette table ne stocke pas uniquement des références.

Voici tout ce qui diffère d'une relation Many-to-Many classique :

• Le stockage en base de données est différent, la table de jointure doit avoir une colonne clé primaire. (contrairement à la relation Many-to-Many classique où l'on ne veut justement pas de clé primaire).
• Il faut créer un modèle pour cette relation. Donc un modèle correspondant à la table en base de donnée.
• Il n'y a pas de convention pour le nom de la table. Nous ne sommes pas obligé d'appeler la table DoctorPatients. Il est même conseillé de donner un nom plus adéquat pour ces tables. Nous l'appellerons Appointments.

Dans la pratique

Avant de continuer, voilà une représentation de la relation des modèles entre eux.

Préparer la base de données

Créons rapidement les modèles Doctor et Patient.

$ rails generate scaffold Doctor  name:string speciality:string
$ rails generate scaffold Patient name:string

Comme je vous l'ai dit, il est nécessaire de créer un modèle correspondant à la table de jointure :

$ rails generate model Appointment

On ne crée que le modèle car aucune vue ou contrôleur n'a besoin d'y être associé. De plus, le fait de passer par la commande rails permet d'avoir le modèle et la migration générés en une fois. Il faut maintenant éditer la migration générée pour qu'elle corresponde à ce que l'on veut :

# db/migrate/x_create_appointments.rb
class CreateAppointments < ActiveRecord::Migration
  def self.up
    create_table :appointments do |t|
      t.references :doctor, :patient
      t.datetime   :appointment_date
      t.timestamps
    end
    add_index :appointments, [:doctor_id, :patient_id]
  end
  def self.down
    drop_table :appointments
  end
end

Comme dans la relation Many-to-Many classique, on spécifie les références aux modèles Doctor et Patient . Puis on rajoute les informations nécéssaires à la description de la relation entre les deux objets. On peut également rajouter les indexes pour doctor_id et patient_id qui sont les clés qui serviront à la base de données lors de la recherche dans la table.

On notera que cette table DOIT avoir une clé primaire, c'est pour ça que l'on n'a pas mis :id => false après le create_table.

Adapter les modèles

Maintenant que la table de jointure est crée, il faut renseigner dans les modèles la façon dont ils sont liés entre eux.

# app/models/doctor.rb
Class Doctor < ActiveRecord::Base
  has_many :appointments
  has_many :patients,    :through => :appointments
end
# app/models/patient.rb
Class Patient < ActiveRecord::Base
  has_many :appointments
  has_many :doctors,     :through => :appointments
end
# app/models/appointment.rb
Class Appointment < ActiveRecord::Base
  belongs_to :doctor
  belongs_to :patient
end

Comme vous le voyez, on n'utilise plus has_and_belong_to_many. Maintenant, les docteurs ont plusieurs patients et vice-versa à travers la table Appointment. Dans cette table seront stockées les informations qui lient les docteurs aux patients. C'est pour cela que l'on utilise le mot clé :through. On indique à Rails que s'il veut trouver les patients liés à un docteur il devra passer par la table Appointments pour les trouver.

Comment utiliser ces relations dans les contrôleurs

Manipuler les associations (ici des «appointments»)

Plusieurs moyens s'offre à vous pour créer un Appointment qui lie un Doctor et un Patient. En voici un exemple :

# @patient et @doctor contiennent une instance d'un docteur et d'un patient
Appointment.create(:doctor => @doctor, :patient => @patient, :appointment_date => Date.tomorrow)

Vous pouvez également créer une association sans spécifier tous les champs, juste en ajoutant un nouveau patient à la liste des docteurs ou vice-versa :

@doctor.patients << @patient
# Ou bien 
@patient.doctors << @doctor

Cela créera automatiquement un Appointment avec les bonnes valeurs pour doctor_id et patient_id, mais tous les autres attributs (ici, la date) seront fixés à null.

Si vous voulez réaffecter toute la liste des patients ou des docteurs vous pouvez faire comme suit :

@doctor.patients = @new_array_of_patients

Ici plusieurs choses sont à noter :

• des appointments sont créés pour lier les nouveaux patients au docteur ;
• si des patients de la nouvelle liste étaient déjà présents, leurs appointments ne seront pas supprimés ;
• les appointments de tous les patients qui ne sont pas dans la nouvelle liste seront supprimés.

Supprimer une association

Comme je l'ai dit précédemment, en réaffectant de nouveaux patients à un docteur, ses anciennes associations seront automatiquement supprimées. Si vous voulez supprimer une association en particulier, vous pouvez simplement faire comme suit :

# On supprime tous les appointments qui existent entre @doctor et @patient
@doctor.patients.delete(@patient)
# Ou bien
@patient.doctors.delete(@doctor)
# Ou encore, pour supprimer les appointments qui ont une date antérieur à aujourd'hui
@patient.appointments.where("appointment_date < ?", Date.today).delete

Les helpers Rails

Rails crée également un tas de helpers qui peuvent être très sympa et que vous trouverez dans l'API Rails. Voici un un avant goût :

@doctor.patient_ids
@doctor.patients.delete_all
@doctor.patients.size
# Etc.

Également utile pour créer des «raccourcis»

Vous pouvez vous servir des has_many :through pour vous faire des raccourcis. Je m'explique. Supposez qu'un document à plusieurs sections et que les sections ont plusieurs paragraphes comme le montre le schéma suivant :

Il peut arriver que vous ayez besoin d'accéder à tous les paragraphes d'un document. Pour faire cela, vous pouvez par exemple définir vos relations comme suit :

# app/models/document.rb
class Document < ActiveRecord::Base
  has_many :sections
  has_many :paragraphs, :through => :sections
end
# app/models/section.rb
class Section < ActiveRecord::Base
  belongs_to :document
  has_many :paragraphs
end
# app/models/paragraph.rb
class Paragraph < ActiveRecord::Base
  belongs_to :section
end

Et donc pour accéder à tous les paragraphes d'un document il suffit de faire :

@document.paragraphs

Voilà, vous devriez avoir toutes les clés pour mettre en place vos relations. Si vous avez des questions ou des améliorations à proposer n'hésitez pas à laisser un commentaire !

Références

• Guide rails sur les associations
• API Rails sur les associations

• avoir des bases en SQL (table, clé primaire, clé étrangère ;
• avoir vu les associations One-to-Many.

Présentation du problème

Lorsque l'on conçoit une application on tombe souvent sur un problème simple : un objet A peut avoir plusieurs objets B et un objet B peut avoir plusieurs objets A... Bon, tout ceci n'est pas très clair, mais quand on l'illustre par un exemple ça le devient.

Prenons un exemple très courant : Elèves - Cours. Un élève peut avoir plusieurs cours et appartenir à plusieurs cours. Ou encore avec un autre exemple : Articles - Tags. Un article peut avoir et peut appartenir à plusieurs tags. Effectivement un tag n'est pas unique, ce n'est pas parce qu'un article a le tag Ruby qu'aucun autre article ne pourra avoir ce même tag.

En théorie

Cette association ressemble à une double association One-to-Many, mais le problème est : « Où mettre la/les clé(s) étrangère(s) pour connaître les associations entre les objets ? »

Pour ça, il faut créer ce que l'on appelle une table de jointure (ou d'association) pour stocker les couples de clés étrangères appartenant aux deux modèles concernés. Il est important de noter que cette table d'association ne sera constituée uniquement de deux colonnes qui contiendront des clés étrangères. En d'autres termes, cette table ne doit pas contenir de clé primaire.

En pratique

Avant de continuer, voilà une représentation de la relation des modèles entre eux.

Création des modèles

Prenons l'exemple des Articles et des Tags. Nous avons donc deux modèles, le modèle Article et le modèle Tag et nous voulons pouvoir associer plusieurs tags à un article mais également plusieurs articles au même tag. Commençons par créer les deux modèles à l'aide des scaffolds :

$ rails generate scaffold Article title:string content:text
$ rails generate scaffold Tag name:string

Création de la migration

Bon, comme vous vous en doutez, la table de jointure ne vas pas se créer toute seule. Pour la créer nous allons passer par une migration (hors de question de la créer à la « main » !)

Les migrations sont un moyen pratique de modifier la base de données de façon structurée et organisée. Elles décrivent des actions à effectuer comme créer une table, ajouter/supprimer une colonne à une table, etc. Elles permettent également de garder une trace de toutes les modifications effectuées sur la base de données.

Convention de nommage

Mais avant de faire ça, comme le principe de Rails est « Convention Over Configuration », il faut bien comprendre comment nommer cette table de jointure. Voici les conventions à respecter pour le nom de cette table :

• nom_modèle_1 + _ + nom_modèle_2 ;
• Les deux noms de tables doivent être au pluriel ;
• Les noms des tables sont ordonnés alphabétiquement. Donc Articles vient avant Tags.

Dans notre cas, le nom sera donc : articles_tags. Article en premier car il est alphabétiquement avant Tag, et les deux noms au pluriel. Si le nom d'un de vos modèles est en plusieurs mots, il suffit de remplacer les espaces par des « _ ».
Exemple : Le nom d'une table de jointure pour un modèle BlogPost et un modèle Category serait blog_posts_categories.

Pour les anglophobes : faites bien attention au pluriel anglais pour les mots qui se finissent en « y ». « One category but two categories ! »

Le fichier migration

Maintenant que nous savons comment nommer cette table et que l'on sait qu'elle ne doit pas avoir de clé primaire nous pouvons créer la migration. Tâchez de donner un nom explicite à celle-ci (celui du fichier qui apparaitra dans le dossier db/migrations), cela pourrait vous servir à l'avenir si vous avez besoin de revenir en arrière.

$ rails generate migration CreateArticlesTagsJoinTable

Il faut maintenant éditer cette migration pour y ajouter l'instruction de création de la table avec le bon nom (comme nous avons vu ci-dessus).

# db/migrations/20111009221942_create_articles_tags_join_table
class CreateArticlesTagsJoinTable < ActiveRecord::Migration
  def self.up
    create_table :articles_tags, :id => false do |t|
      t.references :article, :tag # Pour créer les clés etrangères
    end
    add_index :articles_tags, [:article_id, :tag_id] # Optionnel
  end
  def self.down
    drop_table :articles_tags
  end
end

Comme on le voit, il faut absolument préciser :id => false pour qu'aucune clé primaire ne soit créée. L'instruction add_index est optionnelle mais permet d'accélérer les recherches en base de données.

Ensuite, pour exécuter la migration il vous suffit d'éxécuter la commande suivante :

rake db:migrate

Adaptation des modèles

Il ne reste plus qu'à spécifier aux modèles les associations et le tour est joué ! Traduction : dire aux Articles qu'ils ont et appartiennent (has_and_belongs) à plusieurs (to_many) Tags. Et vice-versa !

# app/models/article.rb
class Article < ActiveRecord::Base
  has_and_belongs_to_many :tags
end
# app/models/tag.rb
class Tag < ActiveRecord::Base
  has_and_belongs_to_many :articles
end

Utilisation dans les vues

Vous pouvez être amené à vous demander comment gérer ces dépendances dans un formulaire. Par exemple, lors de la création d'un article je voudrais pouvoir choisir tous les tags qui lui seront associés. Voilà une méthode pour faire ça :

# app/views/articles/_form.html.erb
<%= form_for @article do |f| %>
  <label>Title: <%= f.text_field :title %> </label>
  <% Tag.all.each do |tag| %>
    <label><%= tag.name %>
      <%= check_box_tag "article[tag_ids][]", tag.id, @article.tags.include?(tag) %>
    </label>
  <% end %>
  <%= f.submit %>
<% end %>

Ce qui se passe ici c'est que lors de la création d'un article on va chercher tous les tags existant en base de données (Tag.all) et on affiche une checkbox pour chacun de ces tags. Ce formulaire servant également pour l'édition, on regarde si l'article n'a pas déjà ce tag (@article.tags.include?(tag)) et si oui, la checkbox sera cochée.

De plus, il n'y a rien a changer du côté du contrôleur, l'affectation des tags à l'article se fera automatiquement grâce au nom de l'input qui est article[tag_ids][]. En effet, dans la methode create du contrôleur de l'article on retrouve :

# app/controllers/articles_controller.rb
def create
  @article = Article.new(params[:article])
  ...
end

L'article qui va être mis en base de donnée est créé à partir des paramètres qui sont stockés dans le tableau article lors de l'envoi du formulaire.

Utilisation dans les contrôleurs

Une fois toute la partie base de données et modèle mis en place, Rails permet d'accéder aux objets entre eux très simplement. Par exemple, pour accéder à tous les tags d'un article on peut faire :

@article.tags # Renvoie un tableau contenant tous les tags de @article

Pour ce qui est de l'affectation il y a deux possibilités :

@article.tags << Tag.first # On ajoute au tags déjà existant
@article.tags = Tag.first  # On remplace les tags déjà existant

Si vous utilisez l'opérateur =, il faut bien garder en tête que tous les tags que possédait l'article seront remplacés par la nouvelle affectation. Au contraire, si vous utilisez l'opérateur <<, le tag sera ajouté aux tags déjà existant.

Références

• Guide rails sur les associations
• Guide rails sur les migrations

Voilà pour les associations Many-to-Many. Je posterai un article sur les associations Many-to-Many avancées (has_many :through) dans les jours à venir. Si vous avez des questions ou des améliorations à proposer n'hésitez pas à laisser un commentaire !

• Comprendre l'intérêt de chaque fichier et de chaque dossier.

Lorsque que l'on veut se lancer dans Ruby On Rails, il peut arriver que l'on soit un peu perturbé, voire découragé par la quantité de fichiers et de dossiers qui sont générés après avoir tapé la commande suivante :

$ rails new mon_application

En effet, après avoir tapé cette commande, on obtient un dossier se nommant mon_application qui contient une dizaine de sous-dossiers, qui contiennent eux-mêmes d'autres dossiers…

A quoi servent tous ces dossiers ? Où dois-je mettre mon code ?

Si l'on comprend ce que chaque dossier contient, leurs intérêts et ceux dans lesquels on doit travailler, les choses sont de suite beaucoup moins repoussantes. Analysons rapidement chaque fichier et chaque dossier.

Les plus importants

Le dossier app, le dossier où l'on passe 90% de son temps

Ce dossier est certainement celui dans lequel vous allez passer le plus de temps. En effet c'est dans ce dossier que se trouvera le coeur de votre application. D'ailleurs lorsque l'on ouvre ce dossier, on voit ceux structurant l'architecture MVC, avec les dossiers models, controllers et views. On trouve également un dossier helpers où l'on mettra des fichiers qui contiennent des méthodes utiles pour nos vues et nos contrôleurs.

Il est important de respecter l'architecture MVC et de mettre les bons bouts de code au bon endroit, et donc par exemple de faire attention à ne pas mettre une méthode qui correspond au modèle dans le controleur.

Le dossier app contient également un dossier assets qui contient lui-même les dossiers javascripts, stylesheets et images qui eux-mêmes contiennent respectivement les fichiers Javascripts, les fichiers CSS et les images.

Dans les versions de Rails inférieur à 3.1, les dossiers stylesheets, javascripts et images sont dans le dossier public.

Le dossier config

Ce dossier contient comme son nom l'indique tout ce qui correspond à la configuration de l'application. Notamment la configuration de la base de données se fait dans le fichier database.yml et le fichier routes.rb permet de définir les différentes parties de l'application pointées par les URLs. On trouve également un dossier initializers qui contiendra du code exécuté lors du lancement de l'application. Le dossier locales lui contient des fichiers qui vont nous être utiles pour l'internationalisation (I18n) de notre application.

Le dossier db

Ce dossier contient tout ce qui concerne la base de données. Il contient les migrations qui sont des fichiers qui permettent de créer, supprimer, ou modifier des tables et ainsi modifier la base de données.

Le dossier public

Ce dossier contient les fichiers statiques et les ressources compilées comme par exemple des CSS générées à partir de fichier sass ou encore les fichiers Javascript compilés à partir des fichiers coffeescripts.

Le fichier Gemfile

Le fichier Gemfile est un fichier très pratique permettant de spécifier les gems et toutes les dépendances nécessaires au bon fonctionnement de votre application. Vous trouverez la majeure partie des gems sur RubyGem.

Le dossier test

Ce dossier contient tous les éléments qui vont nous être utiles pour pouvoir tester notre application. C'est donc dans ce dossier que l'on va mettre tout notre code de test qui nous permettra de vérifier que chacune de nos classes et chacune de nos méthodes effectuent bien le travail attendu.

Même si les tests peuvent paraître inutiles et qu'il n'est pas nécessaire d'apprendre à en faire dès le début de notre apprentissage, il est important de noter qu'ils sont indispensables afin de produire une application fiable et de qualité.

Les dossiers et fichiers que l'on ne touche pas souvent

Le fichier config.ru

Ce fichier de configuration est utilisé par les serveurs Rack pour démarrer votre application.

Le dossier doc

Ce dossier contient toute le documentation concernant notre application, notamment c'est dans ce dossier que l'on peut stocker nos todos listes ou différentes notes au sujet de notre application.

Le dossier log

Ce dossier contient tous les logs de notre application, cela peut être utile pour savoir ce qu'il se passe dans notre application, puisqu'il contient le détail de chaque action éffectuée par notre application. Par exemple quand on accède à une liste d'éléments contenus dans la base de données, on peut voir la requête SQL effectuée pour récupérer ces données.

Le fichier README

Dans ce fichier nous pouvons écrire les informations que l'on veut communiquer aux personnes récupérant le code source de notre application. Par exemple, on peut indiquer ce que fait l'application, quelles sont les commandes à éffectuer afin de pouvoir l'exécuter, comment la configurer, etc…

Le dossier script

Ce dossier contient initialement le script rails qui permet par exemple de démarrer notre application et de générer des fichiers comme des modèles ou des contrôleurs. Il peut également contenir d'autres scripts que l'on veut ajouter pour déployer ou lancer notre application.

Le dossier tmp

Ce dossier contient tous les éléments temporaires nécessaires à notre application, mais nous n'avons pas à nous en préoccuper.

Le dossier vendor

Ce dossier est destiné au code complémentaire de tierces parties. Dans une application Rails typique, cela comprend des gems Ruby, le code source de Rails (s’il est installé dans le projet) et les plugins contenant des fonctionnalités additionnelles packagées.

Le fichier Rakefile

Ce fichier localise et charge les tâches qui peuvent être utilisées depuis la ligne de commande. Là encore on n'a pas vraiment besoin de s'en préoccuper.

Voilà pour l'ensemble des fichiers et dossiers. Si vous avez des questions ou améliorations à proposer n'hésitez pas à laisser un commentaire !

Références

• Rails guide : Getting Started
• Rails guide : Getting Started (fr)

• comprendre ce qu'est une association One-to-Many ;
• mettre en place une association One-to-Many avec Rails.

Présentation du problème

Le problème est relativement simple, le but d'une association est de pouvoir recréer des relations d'appartenance sur le plan informatique. Par exemple, comment représenter le fait qu'un écrivain possède plusieurs livres ? Ce problème est assez courant dans les applications et Rails nous permet de mettre ça en place assez facilement.

Un exemple concret

Pour bien comprendre comment cela marche, on va prendre un exemple concret. Pour reprendre l'exemple cité ci-dessus, nous avons donc des écrivains qui écrivent des livres. On a donc une application avec des écrivains et des livres et on veut relier ces deux entités ensemble par une relation d'appartenance. En gros :

• un écrivain a plusieurs livres ;
• un livre n'appartient qu'à un écrivain.

En théorie

En "théorie" pour résoudre ce problème, il suffit que chaque livre ait une référence vers son écrivain. Pour être un peu plus théorique, on peut visualiser la relation par un arbre à deux niveaux, l'écrivain étant une racine et tous ses livres étant des feuilles. Dans ce cas-là, toutes les feuilles (livres) ont une référence vers la racine (l'écrivain). En terme de base de données cela donne quelque chose comme ça :

Writer - id:integer  name:string
Book   - id:integer  title:string writer_id:integer(foreign_key)

Comme on le voit là, le livre a une référence vers son écrivain et cette référence est une clé étrangère vers la table Writer.

En pratique

Avant de continuer, voilà une représentation de la relation des modèles entre eux.

Préparer la base de données

Bon, la vraie question maintenant c'est : "Comment on fait avec Rails ?" Eh bien comme on va le voir, ce n'est pas bien compliqué ! On crée tout d'abord nos modèles comme suit :

$ rails generate scaffold Writer name:string 
$ rails generate scaffold Book   title:string writer_id:integer
$ rake db:migrate

Ici on peut noter plusieurs choses. Premièrement, les IDs des modèles sont générés automatiquement, pas besoin de spécifier quoique se soit. Mais surtout, le fait de nommer la référence écrivain writer_id n'est pas anodin. En mettant bien le nom de la table de référence (en minuscule et au singulier) suivit de _id on indique à Rails que c'est une clé étrangère qui correspond à l'identifiant de l'objet Writer.

Mettre les choses en place dans les modèles

Bon, évidemment ce n'est pas tout, mais c'est presque fini ! Il suffit maintenant de spécifier qui appartient à quoi dans les modèles et le tour est joué ! Comme on l'a dit plus haut, un écrivain possède plusieurs (has many) livres. Ou encore, un livre appartient à (belongs to) un écrivain. Je mets en avant ces mots clés, car c'est grâce à ces derniers qu'on va décrire à Rails notre relation. En pratique ça donne :

# app/models/writer.rb
class Writer < ActiveRecord::Base
  has_many :books
end
# app/models/book.rb
class Book < ActiveRecord::Base
  belongs_to :writer
end

Il est important de noter ici le pluriel et le singulier des mots. Un écrivain possède DES livres → Je mets un pluriel. Un livre appartient à UN écrivain → singulier. Si vous avez oublié la syntaxe, voilà un petit mémo : c'est logique. Ah et, j'oubliais de dire que... Voilà, c'est tout.

Utilisation dans le code

Alors, évidemment, le fait de faire ça ne vous change pas vos vues ni vos contrôleurs automatiquement. Si vous cherchez la simplicité il y a des gems comme InheritedResource qui existent pour vous simplifier la vie dans les contrôleurs mais si vous débutez je vous le déconseille.

Dans le contrôleur

Un des endroits ou l'affectation d'un écrivain à un livre peut être utile est dans le contrôleur books_controller. Si vous voulez par exemple affecter toujours le même écrivain à tous les livres, vous pouvez dans, la méthode create du contrôleur books_controller, spécifier l'id de l'écrivain comme suit :

# app/controllers/book_controller.rb
def create
  super_writer = Writer.first
  @book = Book.new(params[:book])
  @comment.writer = super_writer
  # Ou 
  @comment.writer_id = super_writer.id
  ...
end

Comme vous le voyez, vous avez plusieurs façons possibles d'associer un écrivain à un livre. Si au contraire vous voulez attribuer des livres à un écrivain, c'est quasiment pareil :

book_list = Book.all
@writer.books = book_list
# Ou alors
@writer.books << Book.last

Il y a deux façons de faire cette affectation. @writer.books (à condition que @writer soit définit avant) va vous renvoyer un tableau de livres. Vous pouvez donc soit, écraser ce tableau en utilisant l'opérateur =, soit ajouter des livres à cette liste avec l'opérateur <<.

Dans la vue

Un autre cas de figure est possible : vous voulez pouvoir choisir l'écrivain à la création d'un livre. Dans ce cas, on voudrait par exemple que dans le formulaire de création d'un livre on ait la liste de tous les écrivains du site et qu'il suffisse de sélectionner l'écrivain voulut pour l'associer au livre. Voilà une façon de faire :

# app/views/books/_form.html.erb
<%= form_for(@book) do |f| %>
  <div class='field'>
    <%= f.label :title, "Titre" %><br />
    <%= f.text_field :title %>
  </div>
  <div class='field'>  
    <%= collection_select(:book, :writer_id, Writer.find(:all), :id, :name) %>
  </div>
  <div class='actions'>
    <%= f.submit 'Créer le livre'%>
  </div>
<% end %>

Bon, tout ceci mérite quelques explications. En fait, la fonction collection_select est un helper qui va générer du code HTML en fonction de ce qu'on lui passe. Vous pouvez avoir la doc ici si ça vous intéresse. Sinon, ce n'est pas bien compliqué. La fonction prend 5 paramètres obligatoires et deux optionnels. Voyons les dans l'ordre :

Object :

Le nom de l'objet du formulaire. Ici :book car on crée un livre.

Method :

La méthode employée pour récupérer la valeur du select. Ici, la valeur correspond à l'id de l'écrivain, donc :writer_id.

Collection :

la collection d'objet qu'on lui passe. On veut lui passer tous les écrivains, donc Writer.find(:all) ou Writer.all.

Value_method :

la méthode qui va être appelée sur chaque élément de la collection pour récupérer la valeur voulut. Ici on veut l'id de l'écrivain (writer.id) donc la méthode est :id.

Text_method :

La méthode qui va être appelée sur chaque élément de la collection pour afficher la valeur dans la select box. Ici on veut le nom de l'écrivain donc :name. Si l'écrivain avait deux attributs :firstname et :lastname on aurait pu faire une méthode simple dans le modèle pour récupérer le nom sous la forme "#{first_name} #{last_name}". Dans ce cas, il aurait donc fallu mettre le nom de cette méthode plutôt que :name.

Options :

Des options comme {:include_blank → true} pour mettre une première valeur null ou {:prompt => "Choisir un écrivain"} pour mettre un texte à la première valeur.

HTML_options :

Les options html que peut prendre le tag select, comme {:class => "my_select_box"}, etc…

Voilà pour les associations One-to_Many. Si vous avez des questions n'hésitez pas à laisser un commentaire !

Références

• API Rails
• Guide rails sur les associations

Ruby et les Gems

Ruby

Le framework Ruby On Rails étant écrit en Ruby, connaitre quelques bases du langage pourra toujours aider. Pas de panique ! Pas besoin d'être un expert en Ruby pour savoir faire du Rails, mais cela vous aidera dans l'apprentissage de ce framework !

• Site officiel ;
• Le quickstart du site officiel ;
• TryRuby.org - un petit interpreteur interactif.
• RubyMonk - un site interactif pour apprendre le ruby.

Les Gems

Les Gems sont comme des petits modules (ce sont des applications et bibliothèques Ruby empaquetées) que l'on peut ajouter à notre application Rails et qui permettent assez souvent de se simplifier la vie. Par exemple des Gems d'authentification existent et permettent de ne pas à avoir à coder tout un système d'authentification. Il n'est pas nécessaire de savoir se servir des Gems pour commencer à faire du Rails, mais il est toujours bon de savoir qu'elles existent. Voici des liens à connaître où vous pourrez trouver la plupart des Gems :

• RubyGems ;
• Ruby Toolbox.

Le MVC - Modèle-Vue-Contrôleur

Le MVC est une architecture actuellement très répandue et vous sera également utile pour d'autres projets informatiques donc n'hésitez vraiment pas à vous y attarder ! Le concept n'est pas évident et clair du premier coup d'oeil donc n'hésitez pas à lire plusieurs articles pour mieux comprendre. Quoiqu'il en soit le temps aidera également à la compréhension !

Mais nous allons tout de même voir un aperçu de ce qu'est l'architecture MVC autour de laquelle Rails est organisé.

Tout d'abord, les avantages de l'architecture MVC sont les suivants :

• la séparation de la logique métier de l’interface utilisateur ;
• la limitation naturelle des répétitions (DRY) ;
• l’évidence de l’emplacement des différents types de code pour une maintenance facilitée.

Les Modèles

Un modèle représente l’information, les données d’une application et les règles pour la manipuler. Dans le cas de Rails, les modèles sont d’abord utilisés pour gérer les interactions avec les tables dans une base de données. Le plus souvent une table dans votre base correspond à un modèle dans l’application. L’essentiel de la logique métier de votre application est concentré dans les modèles.

Les Vues

Les vues sont l’interface utilisateur de votre application. En Rails, les vues sont souvent des fichiers HTML contenant du code Ruby intégré et dédié à la présentation des données. Les vues ont la responsabilité de fournir des données au navigateur, ou aux autres outils utilisés pour faire des requêtes à votre application.

Les Contrôleurs

Les contrôleurs constituent le lien entre les modèles et les vues. En Rails, les contrôleurs sont responsables du traitement des requêtes entrantes en provenance du navigateur, de l’interrogation des modèles pour obtenir des données, et du passage de ces données aux vues pour leur présentation.

• MVC avec Wikipedia ;
• MVC sur le site du zéro.

REST - Representational State Transfer

REST est un style d'architecture et la vie sera bien plus facile pour vous si vous concevez vos applications Rails comme ceci.

• REST avec Wikipedia ;
• Comment j'ai expliqué REST à ma femme ;
• Pour ne plus être en REST, comprendre cette architecture.
• Gerald's Blog - Qu’est-ce que REST ?
• Aeon Blog - Comprendre REST

Références bibliographique

Vous aimez la lecture ? Vous préférez apprendre avec un bon livre ? Voilà quelques références qui pourraient vous intéresser !

• Agile Web Development with Rails (4th edition) En anglais, certes, mais un très bon livre pour débuter. Des notions de développement agiles sont également enseignées avec ce livre !

Allez voir ailleurs !

Nous vous incitons fortement à aller voir les articles et les tutoriels des autres ! D'ailleurs si vous êtes féru en anglais n'hésitez pas à aller du côté de la communauté anglaise qui possède également beaucoup de ressources. Un tas de personnes font des articles et des tutoriels avec un autre point de vue que le nôtre, une façon de penser qui se rapproche peut être plus de la vôtre. Voilà une liste non exhaustive, évidemment :

• Les RailsGuides. Nous ne pouvons que le conseiller très très fortement. Long et en anglais, mais remplis de la plupart des informations que vous cherchez et chercherez !
• Les Guides Rails La même chose mais en français ! Tout n'est pas traduit, mais vous trouverez une partie des guides en français. (La première page est en anglais mais les guides sont bien en français !) Ces traductions correspondent au répo git du créateur de RailsDébutant.org. Il n'est donc pas forcément à jour par rapport au répo officiel. (N'hésitez pas à contribuer si vous êtes bon en anglais et que vous avez un peu de temps !)
• Les RailsCast Ces vidéos, certes en anglais, sont très concises et très bien présentées par le célèbre Ryan Bates !
• Comment débuter en Ruby on Rails de Camille Roux.

Des choses à ajouter ?

Si vous avez des références intéressantes à conseiller, n'hésitez pas à nous les faire parvenir dans les commentaires pour que nous mettions notre article à jour !