Blog Bang Bang - Tag - ruby

ActionView : Imprimeur de son état

jblanche — Wed, 06 Aug 2008 00:37:00 +0200

3ème et dernière partie du Modèle M.V.C. dans Rails, la Vue.

Comme vous l'avez compris dans la partie précédente, Ruby on Rails est capable de produire ou de servir bien plus que des pages HTML et notamment du XML, du JSON, des images, du PDF... ...
Toutefois, Rails a été particulièrement bien prévu pour la génération de HTML et en facilite grandement l'écriture...

Pour commencer sachez que le langage de templates inclus par défaut dans Rails se nomme erb.
D'autres existent (Builder, HAML... et ont leur intérêt, mais je m'attarderais ici seulement sur erb).

Celui-ci vous permet d'intégrer du code Ruby dans votre code HTML comme vous le faites avec les balises <? et ?> de PHP.

En Ruby deux types de balises existent :

Le code placé entre <% et %> sera interprété, mais pas affiché.
Le code placé entre <%= et %> sera interprété et affiché.

On écrira par exemple pour afficher les informations d'un étudiant (méthode show)

<h1>Présentation</h1>



  Prénom: <%= h @student.firstname %><br />

  Nom: <%= h @student.lastname %><br /> 

   

  <% if @student.major? %>

    Age : <%= @student.age %>

  <% end %>

@student étant la variable passée par notre controller dans la méthode show dans la partie ActionController de ce tutoriel.

N.B. : Je n'ai pas écrit les méthodes major? et age dans mon modèle Student dans le tutoriel sur ActiveRecord mais l'intégralité de cette mini-application (absolument pas fonctionnelle) est disponible sur Github sur mon dépot.
Vous trouverez ce modèle ici

Vous vous souvenez que l'on avait également une méthode update, censée mettre à jour les données d'un utilisateur provenant d'un formulaire.

Écrivons ce formulaire :

<% form_for @student do |s| %>



  <%= s.label :firstname, "Prénom" %><br />

  <%= s.text_field :firstname %><br />

  

  <%= s.label :lastname, "Nom" %><br />

  <%= s.text_field :lastname %><br />

  

  <%= s.label :date_of_birth, "Date de naissance" %><br />

  <%= s.date_select :date_of_birth %><br />

  

  <%= submit_tag "Enregistrer" %>

<% end %>

Pas mal non

Oui ok un coup de CSS ne ferait pas de mal, mais là n'est pas le sujet

En passant le @student à la méthode form_for, celle-ci sait que le formulaire va modifier l'utilisateur existant et grâce à l'utilisation REST, elle peut aisément générer la balise formcorrespondante.

De même, l'utilisation du |s| permet d'appeler les méthodes de rails pour construire un formulaire ( text_field, date_select, hidden_field...) en les associant à notre étudiant et donc de générer le code du formulaire avec les propriété name des input correctement renseignées.

Regardez plutôt le code généré :

<form action="/students/1-Jonathan_Blanchet" class="edit_student" id="edit_student_1" method="post">
  <div style="margin:0;padding:0">
  <input name="_method" type="hidden" value="put" />
  <input name="authenticity_token" type="hidden" value="c810f8897fcc7bab36a440cb4653b4f87de89d6e" />
  </div>

  <label for="student_firstname">Prénom</label><br />
  <input id="student_firstname" name="student[firstname]" size="30" type="text" value="Jonathan" /><br />

  <label for="student_lastname">Nom</label><br />
  <input id="student_lastname" name="student[lastname]" size="30" type="text" value="Blanchet" /><br />
  ...
</form>

Les inputs _method et authenticity_token sont automatiquement renseignés par Rails.

Le premier informe Rails sur le type de requête a utiliser selon la méthode REST (ici PUT) en attendant que les navigateurs implémentent les méthodes PUT et DELETE (seulement GET ET POST sont actuellement supportées).

Le deuxième sert à protéger le formulaire contre des ataques extérieures mais comme le premier, vous n'aurez jamais à vous en soucier

Pour le reste, vous noterez la forme student[propriété] de tous les inputs qui nous permettra de récupérer un tableau student contenant tous les attributs de notre étudiant.

Vous noterez également que les propriétés value ont été automatiquement proprement remplies.

Voilà pour notre formulaire.

Vous vous souvenez surement que nos étudiants doivent avoir un nom et un prénom sous peine d'être "invalides" pour ActiveRecord.

Rajoutons en haut de notre page le code suivant :

<%= error_messages_for 'student' %>

Si on essaye désormais de sauvegarder notre utilisateur sans nom, nous aurons droit à ceci :

Évidemment, tous ces messages sont personnalisables très facilement

Je ne vous parlerais pas ici d'AJAX car même si la facilité de mise en place de fonctionnalités AJAX avec Rails est souvent mise en avant dans les tutoriels, le code généré par Rails dans sa version actuelle n'est vraiment pas parfait et ne respecte pas le principe de séparation du contenu, de la présentation et du comportement (HTML - CSS - Javascript)

Pour les plus curieux, je vous invite à regarder du côté de UJS un plugin permettant d'écrire ce genre de choses :

apply_behaviour '.list_item:click' do |page, element, event|

  element.replace_html "Deleted." 

  event.stop

end

Pour en savoir plus sur la notion de Progressive Enhancement (utilisation propre du Javascript) et sur les CSS-based Selectors, je vous invite à lire cette excellente présentation (c'est court mais excellent) :

Voilà, c'est terminé pour la partie vue et plus largement, pour cette série d'articles.

J'espère vous avoir convaincu de l'intérêt de Ruby et de Ruby On Rails pour écrire vos applications Web.

Pour ma part, je m'étonne encore régulièrement de la facilité à écrire certaines choses en Ruby ! [private joke]Même une mamie Molette blonde pourrait le faire...[/private joke].

Je vous invite maintenant à me laisser en commentaire, toutes vos questions, réflexions, demandes sur cette série d'articles et/ou sur Ruby/Ruby On Rails en général.
J'y répondrais avec plaisir et peut-être sous la forme d'une FAQ qui pourrait faire office de billet de clôture de cette série.

ActionController : Monsieur Circulation

jblanche — Wed, 30 Jul 2008 23:10:00 +0200

Dans Rails, ActionController fait la circulation, il va à chaque requête, appeler les modèles nécessaires pour récupérer les données, puis appeler la méthode render pour afficher une vue, un XML... et vous renvoyer le tout.

La politique Rails veut que les controllers soient légers.

"Skinny Controller, Fat Model"
Jamis Buck, 37signals employee

Et ça tombe bien Rails fourni tout ce qu'il faut pour vous simplifier la vie...

Imaginez par exemple que vous vouliez une interface de gestion de nos étudiants précédemment crées.
Si nos souhaits se limitent à l'ajout, modification, suppression, le scaffold de Rails ferait l'affaire, mais on va ici partir "from scratch" pour vous montrer à quel point tout ceci est aisé.

On créera alors un Controller StudentsController

script/generate controller Students

Rails2.1 permet de faire très facilement des controllers dit "Restful".

Si vous ne savez pas ce dont il s'agit je vous invite à lire l'excellente traduction de Biologeek d'un article de Softies on Rails :
Pour ne plus être en REST, comprendre cette architecture
et/ou celle-ci de pompage.net :
Comment j'ai expliqué REST à ma femme

Si vous avez lu et compris, vous aurez retenu qu'avec REST on utilise tous les verbes du protocole HTTP et qu'on parle de ressources plutôt que de pages web ou d'images...

Les ressources, dans notre cas, ce sont des étudiants et voici quelques URLs qui vont nous intéresser

GET    /students                        :action=>"index"

POST   /students                        :action=>"create"

GET    /students/new                    :action=>"new"

GET    /students/:id/edit               :action=>"edit"

GET    /students/:id                    :action=>"show"

PUT    /students/:id                    :action=>"update"

DELETE /students/:id                    :action=>"destroy"

Vous aurez compris que pour afficher un utilisateur on fera /students/:id, mais et c'est là où REST intervient, on utilisera la même adresse pour le supprimer et le modifier.

En effet une ressource = une URI, donc un utilisateur => "/students/:id"

Par contre, le type de requête HTTP, respectivement GET, DELETE ET PUT nous informera sur ce que l'on souhaite faire.

Avec Rails, les actions appelées sont les méthodes publiques des controllers, écrivons donc la méthode qui va afficher un utilisateur

def show

  @student = Student.find(params[:id])

end

Et voilà...
Quoi c'est tout :D

Oui, pour l'instant cela peut suffire, en effet Rails a récupéré notre ressource (l'utilisateur désiré) grâce au find et par défaut, il va appeler la méthode render avec la vue correspondante (show) dans le dossier des vues.

Cette dernière aura accès aux variables d'instance de notre classe et donc à l'objet @student et toutes ses propriétés.

Essayons maintenant d'écrire la méthode nécessaire à la modification (update) d'un utilisateur.

def update

  @student = Student.find(params[:id])

  @student.update_attributes(params[:student])

  redirect_to @student

end

Dans la première ligne, je récupère l'étudiant à créer.
Dans la seconde j'update ses attributs (donc propriétés) avec les paramètres passés par le formulaire.
Dans la dernière je redirige l'utilisateur vers le student modifié (cela appellera la méthode show précédemment créée)

En réalité il faudrait gérer le fait que la sauvegarde se soit ou non bien passée, cela donnerait donc :

def update

  @student = Student.find(params[:id])

    if @student.update_attributes(params[:student])

      redirect_to(@student)

    else

      render :action => "edit"

    end

end

C'est presque la même chose sauf que si la sauvegarde n'a pas fonctionné, on revient sur la page d'édition.

Voilà pour la version HTML, mais si vous avez compris REST, vous savez que l'on aimerait pouvoir avoir d'autre représentation de notre ressource qu'une page web !
Pourquoi pas par exemple, une représentation XML que l'on pourrait passer à un webservice distant ou je ne sais quel autre usage.

Ré-écrivons notre méthode show dans ce but

def show

  @student = Student.find(params[:id])



  respond_to do |format|

    format.html # show.html.erb

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

  end

end

Et voilà, notre controller répondra désormais à la demande générée.
Si vous lui demandez du HTML, celui là réagira comme précédemment, si vous le voulez en XML, il exécutera la ligne :

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

et renverra donc notre objet student converti en XML.

Vous voulez discuter avec une application Flash/Flex/AIR..., installez RubyAMF (l'équivalent Ruby de AMFPHP) et il vous suffira de rajouter :

format.amf { render :amf => @student }

Et voilà vous avez côté ActionScript votre objet tout chaud sans nécessité de désérialisation.
Et vous n'avez presque rien eu à faire côté Rails et finalement, c'est normal, la logique et la ressource sont les mêmes, seul le rendu change !

Comme vous pouvez le voir, ActionController se débrouille donc très bien pour faire la circulation entre la vue et les modèles.

Une des rares autres tâches qui incombe au controller est le contrôle des accès, si vous souhaitez vérifier que l'utilisateur connecté peut accéder à telle ou telle ressource, c'est à lui de s'en charger.

Imaginons dans notre exemple, que les étudiants puissent consulter les informations les concernant, mais que seul l'intendance puisse les éditer, ajouter, supprimer.

Ajoutons à notre controller la ligne suivante :

before_filter :authenticate , :exept => [:index, :show]

Cela signifie qu'avant toutes les méthodes sauf index et show, on exécutera la méthode authenticate et que l'on ne fera la suite que si cette méthode renvoi true.

On peut donc rajouter à la fin de notre controller la méthode authenticate :

private



def authenticate

  authenticate_or_request_with_http_basic do |username, password|

    username == "foo" && password == "bar"

  end

end

On notera que la méthode a été placée après le mot clé private afin de signifier que celle-ci n'est pas une action exécutable par le navigateur.

Notre action va ouvrir une boite de dialogue (si l'utilisateur n'est pas encore authentifier) nous demandant notre login et mot de passe et renverra true si et seulement si ceux-ci sont "foo" et "bar"
N.B. : Evidement, en réalité, cette vérification s'effectuerait en base de donnée

Et voilà, désormais seul les personnes connaissant les logins et mot de passe ont accès à l'intégralité de l'application.

Ce sera tout pour ce soir, nous avons désormais vu comment écrire du Ruby, puis, comment fonctionnent les parties Model et Controller de Rails.

Il ne nous reste donc plus qu'une partie à aborder : les vues.
A bientôt pour ce dernier chapitre.

ActiveRecord : Vos données, c'est mon dada.

jblanche — Fri, 25 Jul 2008 22:24:00 +0200

Nous allons donc commencer par le M du M.V.C., le modèle :
ActiveRecord c'est le gestionnaire de vos données et donc la plupart du temps, de votre Base de données dans Rails
Ça tombe bien, la partie Base de données est surement la plus magique de Rails...

Question à 100 piasses : Qui aime écrire du SQL ?
Ceux qui ont répondu OUI peuvent s'en aller :D

En effet que ce soit à la création ou au traitement de vos données, vous n'écrirez pratiquement jamais de SQL avec Rails.
Mais alors comment on les crée nos bases ?

La réponse de Rails s'appelle les migrations.
Quand vous voulez créer une nouvelle table, vous créez (ou faite faire à Rails) une nouvelle migration, celle-ci comporte deux méthodes "up" et "down".

De cette manière, il sera aisé pour Rails de revenir en arrière si finalement votre implémentation de la base ne vous plait pas.

La création de ce modèle s'écrira : (à exécuter en console ou dans l'interface de votre IDE)

script/generate model Student firstname:string lastname:string date_of_birth:date section:string promotion_id:integer

On précise que l'on veut créer un modèle, on donne ensuite son nom, puis les colonnes de la base de données avec leur types.

En exécutant ceci, vous créer tous les fichiers de votre modèle dont une migration ressemblant à ceci, dans le up, on crée notre table, dans le down on la supprime.

class AddStudents < ActiveRecord::Migration

    def self.up

      create_table :students do |t|

        t.string        :firstname

        t.string        :lastname

        t.date          :date_of_birth

        t.string        :section 

        #S pour Scientifique, L pour Littéraire, ES pour Economique et Social

        t.integer       :promotion_id  

        t.timestamps

      end

    end



    def self.down

      drop_table :students

    end

  end

Plutôt simple n'est-ce pas ? Et avec ça Rails s'adaptera à votre base de données, qu'elle soit Mysql, Postgresql, Oracle, SQLite...

Et si demain vous changez Mysql pour Postgres, il suffira de faire un petit

rake db:migrate

pour récréer toutes vos tables (En réalité, Ruby éxécutera à la suite toutes les méthodes up de vos migrations).

Vous aurez surement remarqué le promotion_id, on supposera dans ce tutorial que l'on a ailleurs une table Promotion avec notamment l'année de la promo et que ce champ servira à faire le lien entre un étudiant et sa promotion.

Ok, mais cette liaison elle est définie où ? On a pas écrit les contraintes dans notre SQL là ?
Oui c'est vrai, allons donc modifier nos modèles pour changer ça. Et puisque nous y somme, nous indiquerons qu'un étudiant doit forcément avoir un nom et un prénom (lignes not null en quelque sorte)

class Promotion < ActiveRecord::Base

    has_many :students

  end

class Student < ActiveRecord::Base

    belongs_to :promotion

    

    validates_presence_of :firstname

    validates_presence_of :lastname

  end

Difficile de faire plus clair non ?

Oui mais dans le code après comment ça se passe ?

Imaginez que vous souhaitiez récupérer tous les étudiants (en gros un SELECT * FROM students)
vous ferez simplement

Student.all

Si vous voulez récupérer la ligne correspondant à la promotion de 2006 :

promo_2006 = Promotion.find_by_year(2006)

Les étudiants de cette promo :

promo_2006.students

Allez compliquons un peu, il n'y a pas de where, pas de conditions dans nos requête actuelles, ajoutons les :

Disons que l'on ne veut récupérer que les étudiants Scientifiques.
Ajoutons à notre modèle la ligne suivante :

named_scope :scientists, :conditions => {:section => "S"}

EN francais : on nommera "scientists" les étudiants ayant comme section "S"
On peut désormais écrire

Student.scientists

pour récupérer tous les étudiants scientifiques

Ces named_scope sont géniaux, ajoutons-en deux pour trouver les étudiant majeurs et mineurs.

named_scope :majors, :conditions => ['date_of_birth < ?', 18.years.ago]

named_scope :minors, :conditions => ['date_of_birth > ?', 18.years.ago]

On peut maintenant faire dans tous nos Controllers :

Student.majors

Pour récupérer les étudiants majeurs.

Et si l'on veut, dans la promo 2006, les étudiants à la fois majeurs et scientifiques :

promo_2006.students.majors.scientists

Et le tour est joué !
Incroyable non ? (qui me l'écrit en SQL avec la jointure et tout et tout ?)

C'est le moment de citer DHH :

Beautiful code makes happy programmers.
David Heinemeier Hansson, Créateur de Rails

Voilà pour les requêtes, pour créer un enregistrement, c'est tout aussi simple :

jb = Student.create(:firstname => "Jonathan", :lastname => "Blanchet")

La création précédente fonctionnera puisqu'elle remplie bien les conditions décrites précédemment (un étudiant à forcément un nom et un prénom).

Allez un dernier exemple pour la route, imaginez que la personne utilisant cette application souhaite, dans l'interface de création des utilisateurs, pouvoir les lier à une promotion en tapant simplement l'année de celle-ci.

Côté modèle, cela veut dire qu'il va falloir trouver la promotion si elle existe, la crée sinon.

Une fois traduit en Rails cela donne :

Promotion.find_or_create_by_year(params[:year])

Simple non

Allez je vous attend pour la suite, on verra le rôle du Controller.

Rails, la locomotive de Ruby !

jblanche — Fri, 25 Jul 2008 22:20:00 +0200

On a vu dans les deux articles précédents les rudiments de la syntaxe Ruby.
Normalement, vous êtes déjà séduit par ces débuts, mais vous n'avez encore rien vu !
Alors ? Ce Ruby on Rails, qu'est ce donc ?

Rails is the killer app for Ruby.
Yukihiro Matsumoto, Createur de Ruby

Ruby on Rails, ou Rails, en fait, est un framework dédié au développement d'application Web.
Un framework, c'est selon Wikipedia, un ensemble de bibliothèques, d'outils et de conventions permettant le développement d'applications.
Ceux-ci permettent donc de donner un socle commun à toutes vos applications et en facilite du même coup le développement et la maintenance.

Rails a été à l'origine développé pour les besoins de la société américaine 37signals qui devant le succès et l'engouement remporté par l'application au sein de son activité, a décidé d'en extraire un framework qu'elle "donnerait" à la communauté du logiciel libre.

Rails suit les principes déjà énoncés dans les articles sur Ruby et y ajoute deux grandes règles :

La convention plutôt que la configuration
Le principal défaut des frameworks Java était souvent leur configuration au travers de 18 fichiers XML tous plus flous les uns que les autres ! Avec Rails, c'est tout l'inverse : votre table s'appelle Students, votre modèle s'appellera Student... C'est également pour cette raison que Rails vient avec une architecture de fichiers et de dossiers bien précise, l'application ira dans app, les tests dans test...
DRY ou Don't Repeat Yourself
Le code doit être écrit de façon à éviter toute redondance qui compliquerait les phases de maintenances, de test, de debuggage... Les modifications doivent se faire à un endroit et n'impacter que les objets concernés.

En plus de ces deux règles, Rails comme la majorité des frameworks dédié au Web s'articule autour du modèle MVC ou Modèle-Vue-Controller.

Les modèles sont les classes assurent la gestion des données, ils sont habituellement liés à la base de données.
Les vues déterminent comment sont affichées les informations à l'utilisateur. Il s'agit généralement d'une combinaison de code HTML et de Ruby.
Les contrôleurs réagissent aux requêtes utilisateur et répondent d'ordinaire à l'aide des vues.

Pour faire simple, voici le chemin d'une requête web avec Rails :

Vous appelez une page, celle-ci correspond à une méthode, dans un controller.
Celui-ci appelle un ou plusieurs modèles pour récupérer les informations nécessaires pour vous répondre.
Il envoie ces données données à la vue qui va interpréter et renvoyer le code HTML (ou autre) désiré.
La réponse vous est envoyée.

On trouve partout sur internet, des tutoriels vous expliquant comment construire un blog fonctionnel en 10mn, un site en une demi-heure et Youtube en 2 jours
Ces tutoriels, mêmes s'ils incitent souvent les débutants à essayer Ruby et Rails, restent trop basique et trop axé sur un exemple particulier pour vraiment montrer les avantages de Rails.
Je vais donc pour ma part vous parler de chaque grande partie de Rails (selon le MVC) en vous montrant ce qui selon moi, fait la différence entre Rails et le reste du monde

On commence tout de suite avec celui qui va gérer vos données, le modèle de Rails, nommé ActiveRecord, suivez-moi...

Un peu de syntaxe Ruby...

jblanche — Sat, 19 Jul 2008 22:05:00 +0200

Vous avez apprécier l'article précédent ?
Alors, essayons d'écrire un peu plus de Ruby...

Pour commencer, si vous souhaitez tester ces exemples sur votre poste je vous invite à installer Ruby sur votre machine.
Pour les autres, vous pouvez tester en ligne ou vous contenter de lire :).

Pour l'installation, les Linuxiens se débrouillerons avec leur gestionnaire de paquets pour installer les paquets ruby irb et rdoc.

Pour les utilisateurs de Windows, je vous invite à utiliser le one-click install qui vous donnera tout ce qu'il faut pour commencer.

Comme je le disais dans le précédent article, la syntaxe de Ruby peut étonner au premier abord, mais sa lisibilité en est fortement améliorée. Regardons ces quelques lignes tirées ou inspirés du fameux "Why's (poignant) guide to Ruby" et de Softiesonrails pour s'en convaincre.

5.times { print "Hello!" }

Essayons de lire ce bout de code en anglais, Five times print Hello, je vous laisse deviner ce qu'il fait

Un autre exemple :

exit unless "restaurant".include? "aura"

En anglais lu : Exit unless restaurant includes aura
Avec cette ligne, notre programme va se terminer (exit) sauf si (unless) le mot "restaurant" contient (include?) le mot "aura".

On retiendra de cette ligne le unless , assez rare dans les autres langages qui est en fait l'inverse du if ainsi que l'utilisation très judicieuse du point d'interrogation dans le nom de méthode include? pour signifier une question, un test (est-ce que "restaurant" contient "aura" ?.
Vous aurez déduis que les méthodes ce terminant par un point d'interrogation retourneront normalement true ou false.

Allez écrivons maintenant une petite méthode (ou fonction si vous préférez, mais normalement en Programmation Orientée Objet on dit méthode).

Imaginez un appareil photo, écrivons la méthode qui prend une photo.
Celle-ci vérifiera si l'appareil est allumé et s'il reste de la place sur la carte mémoire.

def capture_clicked 

  capture_image if @camera.on? && @camera.memory_available? 

 end

Comme vous pouvez le constater, une méthode Ruby s'écrit avec def et end.
Pour le reste c'est encore une fois plutôt standard, vous remarquerez toutefois qu'en Ruby, on peut écrire la clause if à la fin de l'instruction ce qui améliore la lisibilité.
En effet, ce que l'on veut faire dans notre cas (99% du temps) c'est capture_screen, il est donc logique de le voir tout dès le début de la méthode et pas encadré par un if comme ce serait le cas dans beaucoup d'autres langages.

Imaginons maintenant qu'on vous demande une méthode qui prendrai des photos en mode rafale tant qu'il y a de place, vous écrieriez alors simplement :

def rafale

  capture_image while @camera.memory_available?

end

Allez un dernier exemple pour la route, écrivons une petite classe Etudiant.
Celui-ci aura un nom, un prénom et un âge.
on a déjà tous écrit un truc du style avec une classe avec trois propriétés et leurs "getters".

class Etudiant

{

    private $prenom;

    private $nom;

    private $age;



    function Etudiant(prenom, nom, age)

    {

        $this->prenom = prenom;

        $this->nom = nom;

        $this->age = age;

    }



    function prenom()

    {

        return $this->prenom;

    }



    function nom()

    {

        return $this->nom;

    }

    

    function age()

    {

        return $this->age;

    }   

}

C'est moche n'est-ce pas !
Et bien en Ruby cela nous donne :

class Etudiant



  attr_reader :prenom, :nom, :age



  def initialize(prenom, nom, age)

    @prenom, @nom, @age = prenom, nom, age

  end



end

Alors, vous voyez bien que le mot sexy n'était pas exagéré pour décrire la syntaxe de Ruby

Pour information, si l'on veut aussi les "setters", en PHP ce sera trois nouvelles fonctions en Ruby on remplacera juste :

attr_reader :prenom, :nom, :age

par

attr_accessor :prenom, :nom, :age

et si l'on veut mettre un peu de logique dans le getter, pour récupérer le prénom avec une majuscule au début, il suffira de l'écrire à la main

def prenom

  @prenom.capitalize

end

Vous vous demandez quand même surement ce que sont ces @ que l'on peut voir devant certaines variables.
Ce signe sert à distinguer les variables d'instances (les attributs d'un objet) des variables locales (à une méthode ou autre).
Il existe également des variables notées @@ma_variable, celles-ci sont des variables de classes, elles sont donc attachées à la classe et non à son instance.

Regardez ce petit exemple pour mieux comprendre :

class Voiture

  @@nom = "Renault Clio"

  

  attr_accessor :nom

  

  def initialize(nom)

    @nom = nom

  end

  

  def nom

    @nom.capitalize

  end

  

  def se_presente

    puts "Je suis une "+@@nom+" surnomée "+nom

  end

end

ma_voiture = Voiture.new("titine")

ma_voiture.se_presente

Cet exemple va afficher
Je suis une Renault Clio surnommée Titine.
Vous remarquerez au passage que je peux appeler les méthodes sans les parenthèses, celles-ci sont optionnelles et les conventions veulent qu'on ne les écrive pas quand il n'y a pas de paramètres.

Pour résumer pour les habitués à PHP :
nom équivaut à $nom
@nom équivaut à $this->nom
@@nom équivaut à self::$nom

Alors, c'est qui qui a la plus ~~grosse~~ belle syntaxe ?
Voilà pour ce soir, j'espère que vous avez encore appris plein de belles choses sur Ruby [troll]et je m'excuse d'avance pour les larmes versées lors de votre prochaine tentative de codage en PHP, ActionScript, Cobol ou Fortran :D [/troll]

Ruby, c'est quoi comme langage ?

jblanche — Tue, 15 Jul 2008 22:35:00 +0200

Let's go...

Dans Ruby on Rails, il y a avant tout Ruby !

Ruby c'est un langage informatique, au même titre que PHP, Python, Java, C, C++, l'ActionScript...

Parmis tous ces langages, trois familles existent, les langages compilés, les langages interprétés et les langages intermédiaires.
Pour information voici comment se répartissent certains langages que vous connaissez surement :

Langages compilés : C, C++...
Langages interprétés : PHP, PERL...
Langages intermédiaires : Java, ActionScript...

Pour en savoir plus sur les différences entre ces trois familles de langages, je vous invite à lire l'explication de commentcamarche.net dont la vulgarisation est excellente (je m'étais lancé dans une explication, mais faire clair, simple et concis à ce sujet est vraiment compliqué). Puisque que c'est de lui qu'il s'agit, Ruby est un langage interprété, donc de la même famille que PHP, c'est d'ailleurs lui que j'utiliserais dans les comparaisons à venir puisqu'il est surement le langage interpreté le plus connu (au moins des lecteurs de ce blog).

D'ailleurs contrairement à la croyance qui veut que Ruby soit un truc tout nouveau qui tombera bientôt à l'eau, Ruby est en fait aussi "vieux" que PHP, leur première publication ayant toutes les deux eu lieu en 1995.

Attention toutefois, Ruby est très différent de PHP !

Pourquoi ?

Orienté Web / Peut tout faire

PHP a été crée par un développeur Web pour le développement Web, les bases de PHP viennent de la nécessité pour son créateur Rasmus Lerdorf, d'enregistrer la fréquentation sur son CV...

Ruby quant à lui, a été crée par Yukihiro Matsumotow dit "Matz" en s'inspirant notamment de PERL et Smalltalk, cela veut principalement dire que Ruby a été écrit pour être un langage applicatif "à tout faire" en allant du petit script de classement de vos images aux bibliothèques d'interfaces graphiques (il est en cela comparable au C, C++, Java...).

Non-Objet / Objet

Dans un langage objet, les objets répondent à des messages.
exemple : l'objet maVoiture reçoit un message lui demandant d'avancer donne

ma_voiture.avance()

PHP, lui, n'est pas un langage (entièrement) orienté objet.
D'ailleurs à l'origine PHP n'est pas du tout un langage objet.
Même si depuis la version 5, tout cela a bien évolué.

Toutefois, en PHP, pour mettre en majuscule un mot ou une phrase, on écrira :

strtoupper("jonathan")

On voit bien ici que "l'objet" traité est passé à une méthode au lieu de recevoir un message.

Si vous n'avez pas encore compris, regardez ce que cela donne en Ruby.

"jonathan".uppercase()

Ici c'est bien l'objet (le string) qui reçoit le message lui indiquant de se mettre en majuscule.

Une des particularités de Ruby est qu'absolument tout (ou presque) est Objet.

C'est la raison pour laquelle j'ai pu écrire "jonathan".uppercase() sans avoir auparavant créé une instance de String...

Ruby "comprend" automatiquement que ce qui est entre deux guillemets est un string et répond donc aux méthodes de cette classe.

On touche là une autre particularité de Ruby, le "Duck Typing" ou "Typage Canard" (si ça marche comme un canard et si ça cancane comme un canard, alors ce doit être un canard" ).
Le principe est donc de ne pas forcer le programmeur à utiliser une classe donnée, mais de l'obliger à mettre les données dans le format que nous voulons utiliser.
J'ai écrit "jonathan" entre guillemets, Ruby comprends que cet objet est un String.
Si j'écris [1, 14, 15] ce sera un Array (Tableau), {1=>"aaa", 2=>"b"} sera un Hash (ou tableau associatif)...

Bizarreries / P.O.L.S.

Une autre particularité de Ruby est de suivre au maximum le P.O.L.S ou "Principle of Least Surprise" ("Principe de moindre surprise").

Cela peut sembler une évidence, mais en gros cela veut dire que les méthodes font ce que leur nom laisse penser qu'elles font.

Pourtant, lorsque l'on lit la documentation de PHP, on se rend compte que ce n'est pas toujours le cas :

array_merge( array $array1 [, array $array2 [, array $... ]] )

Merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one.

If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.

If only one array is given and the array is numerically indexed, the keys get reindexed in a continuous way.

La même chose en Ruby (méthode merge de la classe Hash) :

hsh.merge(other_hash)

Returns a new hash containing the contents of other_hash and the contents of hsh, overwriting entries in hsh with duplicate keys with those from other_hash.

Vous voyez la différence, n'est ce pas

[private joke]
On peut aussi en faire la démonstration avec AS3 et Ruby pour retourner un string :

AS3 :

myString.split('').reverse().join('')

Ruby

my_string.reverse()

[/private joke]

Voilà pour la première introduction, j'espère vous avoir donner envie d'en savoir un peu plus et je vous monterais bientot les rudiments de la syntaxe Ruby (certes un peu étrange pour un développeur PHP ou Flash, mais tellement sexy à l'usage !)

See you soon...

Mais Ruby, Ruby On Rails, c'est quoi en fait ?

jblanche — Tue, 15 Jul 2008 21:57:00 +0200

Comme souvent quand quelque chose vous passionne, vous ne pouvez pas vous empêcher d'en faire la promotion autour de vous.

La plupart temps il s'agit d'un groupe de musique, d'une équipe de foot, d'un réalisateur ou d'un acteur et il est assez facile d'expliquer autour de vous pourquoi votre préféré est selon vous meilleur que tous les autres.
Mais quand l'une de vos passions est le Web, vous êtes déjà un peu plus étrange.
Si vous précisez que c'est du développement Web qu'il s'agit, vous devenez carrément bizare.
Et si vous finissez en expliquant que c'est plus particulièrement de Ruby ou Ruby et Ruby on Rails qu'il s'agit, vous devenez aux yeux de votre interlocuteur un extraterrestre !

Et pourtant, c'est mon cas.
Je suis "accroc" à Ruby et Ruby on Rails et je vais donc essayer d'expliquer en quelques billets ce dont il s'agit avec des mots simples.

Suivez moi...

En vrac

jblanche — Wed, 04 Jun 2008 23:47:00 +0200

Pas beaucoup de temps en ce moment (pris par le projet de fin d'année de ma dernière année d'étude), donc je vous livre sans grands discours ce qu'il faut lire, voir, savoir en ce moment :

Yahoo fournit un kit d'éléments d'interfaces Web afin de faciliter la création de Wireframes.
Les UltraPortables fourmillent Eeepc700, 900, 1000, Gigabyte M912, Wind U90... Et quel OS choisit t-on le plus souvent pour faire tourner ce beau monde : Linux ( Et pourquoi mettre autre chose puisque c'est celui qui vous coûtera le moins cher à configuration matérielle égale, qu'il offre un meilleur confort d'utilisation et une meilleure autonomie !)
Ubuntu va développer Ubuntu Netbook Remix : des interfaces dédiées à ces matériels.
Les PC de salon à bas prix débarquent eux aussi (EeeBox) et là encore si vous voulez le moins cher ou mieux pour le même prix, c'est la version Linux qu'il vous faudra choisir.
Facebook libère sa plateforme de développement et encourage du même coup les développeurs à utiliser leur plateforme.

Et pour Ruby, Rails :

Rails2.1 est sorti accompagné de son lot de nouveautés.
La Railsconf avait lieu la semaine dernière et les présentations sont disponibles.
On regardera particulièrement celles-ci (liens vers les PDF) :
- Les bons conseils pour les tests
- Fuzed : une solution intérressante pour gérer la montée en charge derrière Rails (ou autre...).
- La gestion des processus longs grâce aux processus asynchrones avec Ruby et Rails.
- La méta-programmation

Bonne Lecture.

PS : Je ne vous oublie pas pour la dernière partie de ma série sur nos ressources et le "HomeServer", elle arrive bientôt.

Un peu de lecture

jblanche — Thu, 24 Apr 2008 00:08:00 +0200

Je viens de recevoir ceci :

Deux pavés d'environ 850 pages chacun qui ne sont pas près de quitter mon bureau

Ces livres ne sont pas à conseiller aux vrais débutants (qui iront plutôt vers celui-ci chez Eyrolles) puisqu'il ne s'agit pas vraiment de livre aidant à l'apprentissage, mais plus de "bible" de Ruby et de Rails qui vous donneront les outils et méthodes à utiliser pour un problème donné".

J'ai déjà commencé à fouiner un peu dans chacun et les problématiques abordées sont vraiment larges et pour certains plutôt pointues !
Je crois que vais bien m'amuser

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.