Blog Bang Bang - Tag - Tutorial

Sortir des conventions dans Rails - retour d'expérience.

jblanche — Tue, 08 Apr 2008 23:01:00 +0200

Tout d'abord, sachez qu'il ne faut jamais outrepasser les conventions de Rails sans une excellente raison.

Toutefois, il arrive que l'on ai une excellente raison, le cas présenté dans ce billet sera celui (tiré d'une application réelle) d'une base de données assez mal conçue où les noms de tables sont tous au singulier et où, comble du massacre, les id d'une des tables sont sous forme de chaine de caractères.

Bien sur, cette base de données est utilisée par 18 autres applications dans la société et vous ne pouvez en aucun cas en modifier la structure (sinon ce serait trop facile).

Problème N°1 : Les noms de tables.

Notre premier problème est donc que Rails considère par défaut qu'un nom de modèle doit-être un singulier et que le nom de la table correspondante doit être un pluriel.

Nous pourrions donc ajouter à l'un de nos modèles la ligne suivante :

self.pluralize_table_names = false

Mais selon moi, cette propriété étant commune à tous nos modèles, il n'est pas logique de la placer dans l'un d'entre eux. Nous allons donc spécifier cette propriété générale à tous les instances d'AciveRecord ailleurs.

Pour cela, la version 2 de Rails nous offre un dossier config/initializers où placer tous nos scripts à exécuter au démarrage de l'application après les configurations par défaut, c'est donc l'endroit parfait pour rajouter un script "do_not_pluralize.rb" avec pour contenu :

module ActiveRecord

  class Base

    self.pluralize_table_names = false

  end

end

Et voilà, nous venons d'overrider le paramètre pluralize_table_names d'ActiveRecord::Base et désormais, tout est clean.

Problème N°2 : Des chaînes de caractères comme id, drôle d'idée...

Les id de notre table "comment" (nom d'emprunt) sont donc des strings. Cela ne pose aucun problème à activeRecord qui saura évidemment faire un find("a12.bcd.3456789") si "a12.bcd.3456789" est la valeur du champ id de notre enregistrement.

Là où intervient le problème, c'est que comme vous êtes quelqu'un d'attentif, vous savez qu'avec Rails2, REST et les named routes ont enfin droit leurs heures de gloire.

Or, cela implique que l'URL d'accès à votre enregistrement soit de la forme :

/comments pour la liste des commentaires.
/comments/1 pour le commentaire 1
/comments/last pour une méthode supplémentaire last que vous auriez définie et qui vous ramènerait probablement les derniers commentaires.

Or avec notre id, l'url est de la forme "/comments/a12.bcd.3456789".

Rails pense alors que 'a12.bcd.3456789' est une méthode à appeler mais il ne la trouvera évidement jamais.

Edit du 17/04/08
Avant de vous montrer la solution que j'ai utilisé dans mon cas je vais suite au commentaire de Nicolas, de boldr.fr vous montrer une solution qui fonctionnera dans la majorité des cas (mais pas le mien.)

Afin de dire à rails d'utiliser autre chose qu'un id numérique dans les url de la forme "/comments/1" il existe une option des ressources appellée member_path. En modifiant donc votre fichier "config/routes.rb", vous pouvez indiqué à Rails d'utiliser l'id de votre table pour avoir des url de la forme "/comments/a12bcd3456789" comprises par rails.

Il suffit donc de remplacer :

map.resources :comments

par

map.resources :comments, :member_path => '/comments/:id'

Grâce à celà, vous éviterez beaucoup d'ennuis mais malheureusement, la solution ne fonctionne pas si l'id nouveau contient des '.' car rails se sert de ce caractère pour séparer la partie relative à l'url de l'action de la partie relative au format de retour (html, xml, js...).

La solution dans mon cas devait donc venir d'autre part...

Dans le cas que j'ai eu à d'étudier, le salut est venu du fait que la suite de nombre suffixant l'id (ici '3456789') était unique, j'ai donc décider d'utiliser celle-ci comme paramètre de l'URL.

Pour récupérer ce nouvel id (que j'appellerai numeric_id), j'ai donc écrit la méthode suivante :

def numeric_id

    self.id.split('.').last.to_i

  end

Il ne me restait plus qu'à indiquer à rails d'utiliser ce paramètre dans les URL grâce à la méthode to_param ^[1] (toujours dans mon modèle).

def to_param

    "#{self.numeric_id}"

  end

Grâce à cela, j'ai donc des url "/comments/3456789" que Rails analisera sans problème.

Dernières modifications, il faut indiquer aux méthodes agissant sur un seul enregistrement dans le controller (show, edit, update, destroy et celle que vous pourriez créer) d'utiliser notre nouvel identifiant numérique plutôt que celui par défaut.

Pour cela je rajoute une méthode find_by_numeric_id dans notre modèle :

def self.find_by_numeric_id(nid) Comment.find(:first,:conditions => ['id LIKE ? ', '%'+nid.to_s]) end

Et je modifie les méthodes précédemment citées pour utiliser notre find, ma méthode show devient donc :

# GET /comments/1

  # GET /comments/1.xml

  def show

    @comment = Comment.find_by_numeric_id(params[:id])

    

    respond_to do |format|

      format.html # show.html.erb

      format.xml  { render :xml => @comment }

    end

  end

Et voilà vous avez désormais une base seine sur laquelle faire reposer la suite de votre développement.

Je me répète mais ce genre de modification ne doit être utilisé que si vous ne pouvez pas faire autrement

[1]Attention, si vous prévoyez d'utiliser la méthode to_param dans le cas d'un model Active_ressource, allez faire un tour ici afin de résoudre un bug de rails (corrigé dans la version SVN) qui fait que activeressource utilise parfois l'id au lieu de to_param.

Tutorial : créer sa première application Ruby on Rails - Part3

jblanche — Tue, 28 Aug 2007 22:08:00 +0200

Après une trêve due à de trop courtes mais bien agréable vacances, voici la suite de la création de notre application.

Dans ce tutorial, nous apprendrons à rajouter des tags à notre application.

Pour ce faire, je me suis largement inspiré d'un autre tutorial sur stoneageblog.com.

Comme souvent, avec Rails inutile de ré-inventer la roue, et quand ce n'est pas le framework qui vous simplifie la vie, c'est la communauté qui vient à votre secours.

J'ai donc utilisé pour ce tutorial le plugin acts_as_taggable_on_steroids, un plugin servant à créer facilement un système de tags dans votre application.

Pour ce faire, il est nécessaire d'exécuter dans une console à la racine de notre application le script suivant :

script/plugin install http://svn.viney.net.nz/things/rails/plugins/acts_as_taggable_on_steroids/

Une fois le plugin installé, il est nécessaire d'ajouter une migration afin de créer les tables nécessaires à l'introduction des Tags.

script/generate migration add_tags

Remplissez le fichier précédemment crée comme ceci :

class AddTags < ActiveRecord::Migration
  def self.up
    create_table :tags, :force => true do |t|
      t.column :name, :string
    end
    create_table :taggings, :force => true do |t|
      t.column :tag_id, :integer
      t.column :taggable_id, :integer
      t.column :taggable_type, :string
      t.column :created_at, :datetime
    end
  end

  def self.down
    drop_table :tags
    drop_table :taggings
  end
end

Nous créons donc deux tables, la première contiendra les noms des différents tags, la seconde les associe à un objet de type taggable_type qui pour nous sera un Snippet et au taggable_id de l'objet en question.
Cette méthode appelée Polymorphisme permettrait d'appliquer les tags à d'autres modèles (Catégories...) par la suite.

Pour exécuter cette migration, c'est vous commencez à en avoir l'habitude en console que ça se passe.

rake db:migrate

Pour parachever la partie base de données, indiquons à notre modèle Snippet qu'il est taggable (ou susceptible d'être taggé). Pour cela, il suffit d'ajouter la ligne acts_as_taggable dans notre modèle afin d'obtenir quelquechose comme ceci.

class Snippet < ActiveRecord::Base
  acts_as_taggable
  ...
end

Notre base de données est désormais prête à accueillir nos tags, nous allons donc les ajouter au formulaire d'ajout de nos Snippets dans le controller Admin.
Dans la vue new.rhtml, je rajoute le code suivant :

<%= content_tag :label , "Tags (separated by a comma)", {:for=>"cd_tag_list"} %>
<%= f.text_field :tag_list %>

Et voilà, rien de plus ne sera nécessaire, l'ajout des tags à notre application est déjà effectif et une multitude de méthodes sont à notre disposition pour les utiliser. Pour les afficher, je peut par exemple désormais faire :

<%= content_tag :p, @snippet.tag_list, :class => "tag_list"%>

Nos Snippets sont désormais taggués mais il manque un petit nuage de tags afin de rendre cette application vraiment Web2.0 :-D.
Pour ce faire, nous allons créer une méthode tag_cloud dans le helper de notre controller snippets(on pourrait tout aussi bien le mettre dans appliucation_helper si l'on souhaite l'afficher dans l'admin.)

Cette méthode, la voiçie (encore merci à l'article de stoneageblog)

def tag_cloud(tags, classes)
    max, min = 0, 0 
    tags.each { |t| 
      max = t.count.to_i if t.count.to_i > max 
      min = t.count.to_i if t.count.to_i < min 
    }

    divisor = ((max - min) / classes.size) + 1 

    tags.each { |t|
      yield t.name, classes[(t.count.to_i - min) / divisor]
    }
end

Dans un premier temps, la méthode cherche la fréquence des tags les plus et les moins utilisés.
Dans un deuxième temps, elle affecte à chaque tags une classe CSS en fonction de sa propre fréquence.

Pour ce faire, vous devrez donc définir plusieurs styles dans vos CSS.

/* Nuage de Tag*/

.nube1 {font-size: 1.0em;}
.nube2 {font-size: 1.2em;}
.nube3 {font-size: 1.4em;}
.nube4 {font-size: 1.6em;}
.nube5 {font-size: 1.8em;}
.nube6 {font-size: 2.0em;}

Comme je souhaite afficher ce nuage de tags pour toutes les méthodes du controller Snippets (dans la sidebar), j'ai choisi d'ajouter ma propre méthode au controller et de l'appeler pour chaque action.
J'ajoute donc une méthode private (pas accessible directement depuis le web)

private
def tag_cloud
 @tags = Snippet.tag_counts(:order=>'tags.name asc')
end

Puis j'indique au controller d'éxécuter cette méthode avant chaque appel aux autres actions en ajoutant un before_filter à notre controller.

class SnippetsController < ApplicationController
  before_filter :tag_cloud
  ...
end

Reste à afficher ce nuage de tag dans nos vues.
Celui ci étant toujours afficher, je l'ai placé directement dans le layout de notre controller (app/views/layouts/snippets.rhtml)

<% tag_cloud @tags, %w(nube1 nube2 nube3 nube4 nube5) do |name, css_class|  %>
   <%= link_to name,{:controller=>"snippets", :action=>"tagged", :tag=>name} ,:class => css_class %>
<% end %>

Comme toujours, c'est quand on croit en avoir fini que l'on découvre nos oublis. Avoir un nuage de tags, c'est bien joli, mais pouvoir associé à chaque tag une page ou l'on affichera les snippets taggués par celui ci, ça serait quand même plus sympa.

Je vous je propose donc, comme on peut le voir dans le link_to du code précédent, de lier chaque tag vers une page /snippets/tagged?tag=montag.
La méthode tagged n'étant bien sûre pas une méthode de l'architecture REST, il va falloir indiquer à rails que celle ci existe en ajoutant une ligne dans notre fichier routes.rb :

map.resources :snippets, :collection => { :tagged => :get }

Cette ligne indique à rails que le controller snippets bénéficie d'une méthode "tagged" qui retourne une collection (une liste) de snippets et qui sera appelée en utilisant la méthode GET.

Je peut donc écrire dans mon controller la méthode tagged comme ceci :

def tagged
 @snippets = Snippet.find_tagged_with(params[:tag])
 render :action => :index
end

La encore, la méthode find_tagged_with nous est fournie par le plugin acts_as_taggable_on_steroids, ce qui nous simplifie bien la vie
Voilà je crois que c'est tout pour les tags.

L'application à également bénéficié d'un relooking grâce au plugin Skinnable sur lequel je ne reviendrais pas tellement il est facile à mettre en place.

L'application en ligne est plus avancée que dans nos tutos puisque qu'elle bénéficie déjà d'un système de commentaires, de la coloration syntaxique des blocs de code, ainsi que de l'autocomplétion sur les tags qui feront l'objet des prochains tutos.

Le résultat est visible dans mon dépôt de snippets de test

Vous pouvez comme toujours, télécharger le code de l'application.

A bientôt pour la suite

Tutorial : créer sa première application Ruby on Rails - Part2

jblanche — Wed, 01 Aug 2007 00:07:00 +0200

Pour cette deuxième partie du tutorial, je vous propose de construire en quelques minutes l'interface d'administration de notre application, de lui ajouter un petit module de recherche et enfin de modifier la page d'accueil.

Commençons donc par l'interface d'administration :

Je ne reviendrais pas sur les méthodes index et show du controller admin puisque se sont exactement les mêmes que dans le controller snippets.

La méthode new est appellée au clic sur le lien new snippet, elle crée un objet snippet que la vue va nous permettre d'éditer.
La méthode create est appellée au clic sur le bouton "Create snippet", elle crée un objet snippet à partir des données passées en paramètres, le sauvegarde (insertion dans la BD) et nous redirige vers la page d'accueil du controller Admin.

  def new
    @snippet = Snippet.new
  end

  def create
    @snippet = Snippet.new(params[:snippet])
    @snippet.save
    redirect_to admin_path
  end

La méthode edit est appellée au clic sur le lien edit snippet, elle crée un objet Snippet à partir de l'id passé en paramètre pour afficher les valeurs actuelles dans l'édition.
La méthode update est appellée au clic sur le bouton "Save Snippet", elle récupère l'objet Snippet à partir de l'ID, appelle la méthode update_attributes avec les paramètres passés par la vue pour mettre à jour notre Snippet dans la base, puis elle nous redirige vers la vue "Show" du Snippet édité.

  def edit
    @snippet = Snippet.find(params[:id])
  end

  def update
    @snippet = Snippet.find(params[:id])
    @snippet.update_attributes(params[:snippet])
    redirect_to admin_instance_path(params[:snippet])
  end

La méthode Destroy supprime le snippet passé en paramètre et redirige vers la liste.

  def destroy
   Snippet.find(params[:id]).destroy
   redirect_to admin_path
  end

Passons donc aux vues :

La vue index.rhtml du controller admin ressemble à celle du controller snippets à la différence près qu'elle rajoute un lien éditer et un bouton supprimer pour chaque snippet ainsi qu'un lien pour créer un nouveau snippet en bas de page.

La vue show est la même que celle du controller snippets à un lien près.

Les vues new et edit méritent plus de précisions :

<% form_for:snippet, :url => admin_url , :method=>:post do |f| %>
        <%= content_tag :label , "Titre", {:for=>"titre"} %><br />
        <%= f.text_field :titre %><br />

        <%= content_tag :label , "Texte", {:for=>"texte"} %><br />

        <%= f.text_area :texte %><br />

        <%= submit_tag "Create Snippet"%>
<%end%>

La méthode form_for demande plusieurs paramètres. Le premier désigne le modèle en relation avec le formulaire crée (ici snippet). Le deuxième défini l'url d'action du formulaire. Le troisième la méthode d'envoi. A l'intérieur du bloc crée par form_for do ... end, les éléments seront automatiquement associés au modèle correspondant (regardez le paramètre name des champs dans la source générée pour mieux comprendre).

Vous l'avez peut être remarqué, les controllers comme les vues font un usage intensif de l'utilisation des routes automatiquement créees par Rails dans le cas d'une application REST (comme admin_path, admin_instance_path...).

J'ai volontairement choisi le nom admin pour ce controller pour vous montrer une petite spécifité de Rails.
Normalement, les noms des controllers sont au pluriel (comme Snippets) mais si l'on désire nommer son controller Admin (car c'est de l'administration et non pas des administrateurs que l'on parle), on fait face à un petit problème.
En effet, Rails se charge de mettre au singulier admin et nous propose admin, ce qui n'est pas faux, mais très génant puisque des routes devant être différentes ont désormais le même nom.
On doit donc dans ce cas, spécifier dans le fichier routes.rb le singulier que l'on utilisera grâce au paramètre :singular (j'ai pour ma part choisi admin_instance).

  map.resources :admin, :singular => :admin_instance

Il existe un autre problème dans notre application telle qu'elle est actuellement.

En effet, si vous editez ou créez un snippet en plaçant des retours à la ligne dans la description de celui-ci, vous remarquerez qu'à l'affichage, les retours chariots ont disparus.

La raison en est simple, à l'enregistrement, Rails enregistre le texte situé dans la textarea en utilisant le caractère de retour chariot normal à savoir "\n".

Ce comportement est parfaitement logique puisque si nous voulons fournir notre contenu dans différents formats (HTML, XML, PDF...), nous ne souhaiterions pas avoir de marquage HTML dans nos données.

Pourtant à l'affichage dans notre vue, on aimerait bien que ceux-ci soient interprétés et traduit en langage HTML. Rails fournit un moyen très simple d'y parvenir en utilisant la méthode simple_format d'ActionView.

Celle-ci remplacera par exemple les sauts de ligne par des et les doubles sauts de lignes par des paragraphes( )

On aura donc dans nos vues quelquechose comme :

<%= content_tag :p, simple_format(@snippet.texte) %>

Pour poursuivre cette deuxième partie du tutorial, je vous propose de commencer la mise en place d'un moteur de recherche très simple pour nos snippets.

Grâce à ce moteur, je souhaiterais afficher les snippets dont le titre ou le texte contient la recherche faite par l'utilisateur.

Commençons donc par créer la méthode associée dans notre modèle :

def self.find_by_titre_or_texte(search)
	search ||= ""
	self.find(:all,:conditions => ["titre ILIKE (?) OR texte ilike (?)","%"+search+"%","%"+search+"%"],:order => "id desc")
end

Le nom de la méthode est préfixé par self car celle-ci est une méthode du modèle Snippet et non pas une méthode applicable à une instance d'un Snippet.

La première ligne correspond à dire search = search si search existe et la chaine vide "" dans le cas contraire.

La méthode est assez triviale, elle effectue un find avec les paramètres all et conditions.
Le premier indique de récupérer tous les enregistrements (et non un seul).
Le deuxième défini les conditions de la requête, on y demande donc de vérifier si le titre ou le texte IS LIKE "%search%".
En SQL, les % désignent n'importe quelle chaîne de caractère et le I de ILIKE indique de ne pas tenir compte de la casse. Cette requête sera donc traduit en :
SELECT * FROM snippets WHERE titre ILIKE '%search%' or texte ILIKE '%search%' ;

Dans notre controller snippets, la méthode qui nous sert à afficher une liste de snippets est la méthode index.
Nous allons donc lui passer un paramètre search pour lui indiquer de n'afficher que les résultant correspondant à notre recherche.

Le paramètre search vaut par défaut la chaîne vide. De cette façon, la recherche donnera des conditions comme : titre ILIKE '%%' ce qui est vrai pour tous les titres.

Les paramères en GET sont passés en ajoutant ?param1=value1&param2=value2&param3=value3 à l'adresse demandée.
Nous appelerons donc snippets?search=rails pour récupérer tous les snippets traitant de rails.
(ex : http://depot.blogbangbang.com/snippets?search=rails).

J'ai également ajouté un formulaire de recherche simpliste dans le layout afin de pouvoir faire une recherche de partout.

        <% form_tag'/snippets', :method=>:get do -%>
        <%= text_field_tag 'search' %>
        <%= submit_tag 'Search' %>
        <%end-%>

Celui ci appelle donc l'URL snippets en get, et le paramètre de recherche est nommé search comme le paramètre récupéré dans notre controller.

En guise de conclusion de cette deuxième partie, nous allons corriger un autre défaut de notre application.
Vous avez peut être constater qu'à la fin de la première partie, l'adresse : depot.blogbangbang.com amenait à la page d'accueil d'une application RubyOnRails.
Il serait préférable de remplacer ce comportement par défaut par la page d'accueil de notre application, à savoir la page snippets.

Pour celà rien de plus simple, ne sortez surtout pas l'artillerie lourde et les ré-écriture d'URL..., rails s'occupe de tout (oui encore :-D)

Nous lui signifions une seule chose dans le fichier routes.rb

map.connect '', :controler => "snippet"

Supprimons également le fichier index.html dans le dossier public. Et voilà c'est tout ! Grâce à cette ligne, rails sait que si l'url demandé est vide (''), il doit rediriger vers le controlleur snippets qui par defaut éxécutera l'action index.

Voilà, nous arrivons au terme de ce deuxième tutorial, j'espère que vous commencez à saisir la puissance du framework RubyOnRails et le plaisir que peut avoir un développeur à coder grâce à celui-çi.

Dans le prochain épisode, nous ajouterons des tags à nos snippets afin de les trier plus facilement.

Archive pour voir l'état actuel de l'ensemble des fichiers.

Tutorial : créer sa première application Ruby on Rails - Bilan1

jblanche — Mon, 23 Jul 2007 23:34:00 +0200

Après ce premier billet de cette série de tutoriaux, voici l'heure du premier bilan.

Commençons par un bilan "comptable" :

Le premier article à été assez bien accueilli puisque la fréquentation de blog à frôlé les 100 visiteurs uniques vendredi dernier grâce notamment à une petite auto promotion sur railsfrance et blogasty (sans les visites par le flux RSS ~~que je ne suis pas en mesure de calculer puisque je ne suis toujours pas inscrit à un service comme feedburner~~, maintenant ce sera fait on verra le résultat ces prochains jours )

Toutefois, ces articles me prennent un temps fou à écrire et j'avoue que je m'attendais à un peu plus de retour en matière de commentaires notamment.
Alors, certains diront que j'insiste mais si vous pensez suivre cette série de tutoriaux, laissez moi un petit commentaire, ça motive

Faisons maintenant le point sur ce que nous avons appris :

On aura tout d'abord remarqué qu'une application rails peut s'exécuter par défaut sur trois environnements : development, production et test.
Ces trois environnements permettent d'obtenir des comportements différents de l'application ainsi que des bases de données différentes.

On peut donc choisir d'afficher toutes les erreurs, d'insérer des données "virtuelles"... dans l'environnement de développement pour tester de nouvelles "features" pendant que l'environnement de production continuera a tourner a merveille.
L'environnement de test est un peu a part puisque les données n'y sont pas conservées à l'arrêt de celui ci, il est donc réservé comme son nom l'indique, à la phase de tests

On a également découvert le mécanisme de migrations de rails. Celui ci permettra au fur et à mesure de l'avancée de notre projet, d'ajouter des colonnes, des tables... en ayant toujours la possibilité de revenir facilement en arrière et de conserver l'intégrité de nos données.

Enfin, nous avons découvert quelques une des méthodes d'ActionView, la classe qui rend l'écriture de vues encore plus simple :

Je sais que certains d'entre vous ont été "choqués" part le fait que les vues ne contenait pas la moindre miette d'HTML, sachez que cela n'est en rien une obligation et qu'il est tout a fait possible d'écrire vos vues en HTML en insérant le code ruby seulement pour les données, mais cela reviendrait à se priver d'un mécanisme vous permettant d'être pratiquement certains d'écrire du code valide XHTML, et qui s'avère à la longue bien plus clair qu'un audacieux mélange entre langage à balise et langage de script.

Enfin je reviendrais ici sur un détail évident après quelques heures de codage mais qui ne l'est donc pas pour les vrais novices, sachez donc que dans les vues, les balises <% %> entoure un code ruby sans rendu tandis que les contenus placés entre <%= %> seront eux automatiquement affichés par rails.
Enfin le signe "-" placé après le tag d'ouverture ou avant le tag de fermeture indique que rails ne doit pas imprimé des caractères d'espaces ou de retour charriot situé après ou avant le tag (cela n'aura la plupart du temps d'influence que sur la présentation des sources.)

Je vous dis désormais à bientôt pour la deuxième partie du tutorial, l'interface d'administration.

Tutorial : créer sa première application Ruby on Rails - Part1

jblanche — Thu, 19 Jul 2007 21:35:00 +0200

Allez, cette fois, c'est parti !
Si vous n'avez pas encore installé ruby on rails et radrails je vous invite a suivre ce tutoriel.

Pour ce premier tutorial, nous allons créer une version très simplifiée de notre application.

Celle-ci s'appellera Depot, nous devons donc créer les bases de données depot_development, depot_test et depot_production sous notre système de bases de données préféré, pour moi ce sera Postgresql mais les fan de Mysql peuvent l'utiliser (avec l'outil Phpmyadmin par exemple).

Nous devons maintenant indiquer à notre application comment se connecter à la base de données. Pour cela, éditez le fichier database.yml (situé dans le dossier config) pour obtenir quelquechose comme cela.

development:
  adapter: postgresql
  database: depot_development
  username: depot
  password: toto

test:
  adapter: postgresql
  database: depot_test
  username: depot
  password: toto

production:
  adapter: postgresql
  database: depot_production
  username: depot
  password: toto

La syntaxe parle d'elle même, remplacez simplement postgresql par mysql si nécessaire.

Ensuite, créons le premier modèle (et donc la première table de notre base de données), le modèle Snippet. Pour ce faire, deux méthodes :

Soit via l'onglet Generator de radrails, choisir modèle dans la liste, puis tapper snippet dans le champ texte
Soit, et ce sera ma méthode pour le reste de l'application, dans une console à la racine de l'application :
ruby script/generate model snippet

Nous venons de créer notre modèle et tous les fichiers associés.

Le premier que nous éditerons est le fichier de migration généré par la création du modèle.
Celui-ci se trouve dans db/migrate et se nomme : 001_create_snippets.rb

Ces fichiers servent à créer notre base de données, en les renseignant avec la syntaxe de Rails, celui ci se chargera d'aptader le code pour le système de gestion de base de données que vous avez choisi (MySQL, Postgres...).

Chaque fichier de migration comporte deux méthodes. La méthode up définie ce que nous souhaitons modifier dans la base de données tandis que la méthode down contient ce que ruby devra faire si l'on souhaite revenir en arrière.

Dans notre cas nous créons donc une table snippets avec les champs titre et texte dans la méthode up, et de quoi détruire cette table dans la méthode down.
Voilà le résultat :

class CreateSnippets < ActiveRecord::Migration
  def self.up
    create_table :snippets do |t|
      t.column :titre, :string
      t.column :texte, :text
    end
  end

  def self.down
    drop_table :snippets
  end
end

Après avoir faire ceci, retournons dans la console et éxécutons :

rake db:migrate

Ruby devrait avoir créer notre table et les champs associés.

Pour commencer, nous allons entrer des données de test dans ces tables en écrivant dans le fichier snippets.yml dans test/fixtures.

Voilà comment j'ai rempli le mien :

ruby:
  id: 1
  titre: "Save some time"
  texte: "Use Ruby on Rails"

two:
  id: 2
  titre: "Improve your user experience"
  texte: "Use Mozilla Firefox"

Note : Les tables ruby contiennent automatiquement un enregistrement ID

Nous allons maintenant créer nos premiers controllers.
J'ai choisi d'en créer deux pour commencer, un controller Admin depuis lequel on pourra ajouter, modifier et supprimer nos Snippets (accessible seulement par les administrateurs) et un controller Snippets qui sera le site accessible par tout le monde.

Allez lancons nous :

ruby script/generate controller snippets

puis

ruby script/generate controller admin

Ces deux scripts ont à leur tour créés quelques fichiers et dossiers notamment les fichiers snippets_controller.rb et admin_controller.rb ainsi que les dossiers app/views/snippets et app/views/admin.

Pour le moment, rendons nous dans le fichier routes.rb situé dans le dossier config.
Ce fichier sert à configurer le lien entre votre application et les url qui lui sont associées.

Nous allons donc appliquer nos propres routes (celles par défaut correspondent à une application non REST).

Pour cela, ajoutons deux lignes au fichier pour obtenir la chose suivante :

ActionController::Routing::Routes.draw do |map|
  map.resources :admin, :singular => :admin_instance
  map.resources :snippets
  
  map.connect ':controller/:action/:id.:format'
  map.connect ':controller/:action/:id'
end

Grâce à ces deux petites lignes l'application est désormais RESTFUL et notre travail sera bien facilité. Je reviendrais dans un prochain billet sur le :singular pour les curieux).

Il ne nous manque plus grand chose pour avoir une application en état de fonctionnement.
Je vous propose pour terminer ce premier tuto d'écrire les controllers et vues de la partie Snippets (accessible à tous) de notre site.

Pour cela éditons le fichier snippets_controller.rb dans app/controllers.

class SnippetsController < ApplicationController
  def index
    @snippets = Snippet.find(:all,:order => "id desc")
  end

  def show
    @snippet = Snippet.find(params[:id])    
  end
end

Est-t'il nécessaire d'expliquer le code tellement celui-ci est simple ?
Allez je vous le fais quand même
La ligne : @snippets = Snippet.find(:all,:order => "id desc") permet de stocker dans la variable @snippets un objet contenant les Snippets renvoyés par le modèle Snippet quand on lui demande de chercher (find) tous les snippets (:all) en les ordonnant par leur id avec les plus élevés en premiers (:order => "id desc") .

La ligne @snippet = Snippet.find(params[:id]) demande elle au modèle Snippet de chercher l'enregistrement ayant l'id passé en paramètre.

Avec seulement ces deux petites lignes, nous avons tout ce qu'il nous faut pour afficher nos vues.

Rendez-vous donc dans le dossier views/snippets pour créer les deux vues :
Commençons par la vue dédiée à l'affichage d'un snippet que l'on nommera show.rhtml :

<%= content_tag :h2, @snippet.titre %>
<%= content_tag :p, @snippet.texte %>

et poursuivons avec la vue pour les lister nommée index.rhtml :

<% @snippets.eachdo |snippet| %>
  <% content_tag :div, :class => "snippet" do -%>
  <%= content_tag :h2, (link_to snippet.titre, snippet_path(snippet)) %>
  <%= content_tag :p, snippet.texte %>
  <% end -%>
<% end %>

Sachez simplement pour l'instant que le : <% @snippets.each do |snippet| %> permet d'itérer sur l'objet contenant tous les snippets et que la méthode content_tag écrit le tag HTML passé avec le premier paramètre et contenant le deuxième (ex : content_tag :p, "Hello" affichera Hello)

Si vous reproduisez ce tutoriel chez vous, récupérez les fichiers snippets.rhtml (app/views/layout) et snippets.css (public/stylesheets) pour customiser votre interface.

Pour la lancer, éxécutez ruby script/server dans le terminal, celle-ci devrait alors être accessible à l'adresse http://0.0.0.0:3000.
Pour les autres, ma version est disponible ici : http://depot.blogbangbang.com/snippets

Sachez toutefois que la partie <%= yield %> dans le layout ne doit pas etre suprimée puisqu'elle correspond à l'endroit ou s'afficheront les données des vues.

Voilà nous arrivons au terme de ce long tutorial, pas mal de chose à mettre en place pour la première version de cette application mais toute ces choses ne seront plus à refaire et nous permettent désormais d'avoir une miriade de possibilités pour la suite.
Je reviendrais dans le prochain billet sur quelques points précis de ce tutorial et nous crérons ensuite l'interface d'administration.

Archive pour voir l'état actuel de l'ensemble des fichiers.

Tutorial : créer sa première application Ruby on Rails - Intro

jblanche — Thu, 19 Jul 2007 00:25:00 +0200

Je les avais promis depuis très longtemps, les tutoriaux sur Ruby on Rails arrivent enfin sur ce blog.

Il me fallait une application à la fois très simple (pour pouvoir l'expliquer correctement) mais néanmoins assez etoffée pour tenir quelques tutos.
Ce que je vous propose, c'est donc de créer un site qui contiendra un dépot de code (ou snippets).
Ce dépot peut servir à recopier rapidement un petit bout de code qui vous a été utile et que vous aimeriez retrouver facilement.

Un exellent exemple de ce genre de dépot est Snipeet, propulsé par Symfony un "équivalent" PHP de rails, dont vous pouvez consulter un exemple sur le site snippets.prendreuncafe.com[1].

Dans cette série de tutoriaux nous allons donc créer une application comme Snipeet qui contiendra, au fur et à mesure, la gestion des tags, la recherche, un système de votes...
On pourra bien sur immaginer d'autres fonctionnalités en fonction de vos retours (si tant est qu'il y en ait).

Pour cette application, j'ai choisi d'utiliser un modèle d'architecture REST.
Je ne reviendrais pas ici sur les spécificités de cette architecture mais je vous invite à lire les articles ou diaporamas suivants :

L'incontournable wikipedia fr
Biologeek qui explique le principe avant de s'attaquer à la réalisation avec Django
Un diaporama résumant très bien son implémentation dans Ruby on Rails

Sachez enfin que cette série de tuto, à évidement pour but de partager les quelques connaissances que j'ai acquis après quelques mois de développement en Ruby on Rails mais également d'améliorer mon niveau avec ce framework.

J'apprenderais donc parfois en même temps que vous et je vous invite à critiquer mes choix, mon code quand vous trouverez à redire (ce qui ne manquera pas d'arriver).

Ca vous tente ? Alors suivez moi

[1] Vous êtes également invité à vous rendre sur le blog, tout aussi excellent.