Installation d’Easyb

Easyb est un outil permettant d’implémenter le BDD dans un projet Java, bien que le code à écrire pour rédiger vos spécifications sera du Groovy, dont la syntaxe est plus légère (plus agile) que Java. Il est comparable à l’outil specs en Scala ou encore RSpec en Ruby.

Pour l’intégrer à votre projet, vous disposez de multiples possibilités : ligne de commande, Ant, Maven ou encore l’intégration avec les IDE IntelliJ et Eclipse.

Il m’a été impossible d’installer le plugin Eclipse, l’adresse du plugin donnée sur le site officiel n’ayant plus l’air d’exister ! Je me suis donc penché sur la solution Maven. Créons donc le projet :

mvn archetype:create -DgroupId=fr.chosesafaire -DartifactId=easyb -Dpackagename=fr.chosesafaire

Editons le fichier de projet pom.xml pour y inclure Easyb, qui sera appelée lors de la phase test :

<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<modelVersion>4.0.0</modelVersion>
<groupId>fr.chosesafaire</groupId>
<artifactId>easyb</artifactId>
<packaging>jar</packaging>
<name>easyb</name>
<version>0.0.1</version>
<description>Test de Easyb</description>
<url>http://www.chosesafaire.fr</url>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.5</source>
                <target>1.5</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.easyb</groupId>
            <artifactId>maven-easyb-plugin</artifactId>
            <version>0.9.6</version>
            <executions>
                <execution>
                    <goals>
                        <goal>test</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.7</version>
        <scope>test</scope>
    </dependency>
</dependencies>

</project>

Nous développerons dans cet exemple une classe HelloMachine, qui n’a pour but que de renvoyer « Hello » et de stocker le fait d’avoir été appelée. Voici le scenario, à placer le fichier src/test/easby/HelloMachineStory.groovy, répertoire qui peut être facilement paramétré depuis le fichier Maven :

import fr.chosesafaire.HelloMachine

/**
 * Calling the HelloMachine !
 */
scenario "calling the hellomachine", {
    given "an hellomachine", {
        machine = new HelloMachine()
        hello = "Hello"
    }

    when "sayHello is called", {
        sayHello = machine.sayHello()
    }

    then "hello should be returned", {
        sayHello.shouldBe hello
    }

    and "then the machine should have been called", {
        machine.isCalled().shouldBe true
    }
}

Et enfin notre classe métier :

package fr.chosesafaire;

public class HelloMachine {
    private Boolean called = Boolean.FALSE;

    public String sayHello() {
        called = Boolean.TRUE;
        return "Hello";
    }

    public Boolean isCalled() {
        return called;
    }
}

Il ne reste qu’à lancer la compilation et les tests :

mvn compile test

Si vous n’avez pas Groovy d’installé, Maven le fera pour vous, car c’est une dépendance d’Easyb. Le résultat dans la console devrait être le suivant (bien qu’il soit possible de générer des rapports HTML !) :

[java] Running hello machine story (HelloMachineStory.groovy)
[java] Scenarios run: 1, Failures: 0, Pending: 0, Time Elapsed: 0.313 sec
[java] 1 behavior run with no failures

Ceci n’est qu’une brève introduction, j’espère que vous comprendrez l’intérêt d’un tel outil en étudiant plus en détail les fonctionnalités ! Voici une liste de liens utiles :

• La documentation officielle
• Maven Easyb Plugin
• Le wiki d’Easyb
• Quelques détails concernant le Behavior Driven Development

Articles liés :

1. VRaptor, le framework qui a les crocs
2. Mocks et Multithreading

L’idée est donc de créer un plugin pour jQuery qui va se substituer au chargement Ajax classique et stocker dans la mémoire du navigateur un bout de page pendant la durée de la session. Le site que j’ai équipé de ce système charge de cette façon 3 ou 4 éléments sur chaque page visitée (le pied de page, un bloc de connexion, un moteur de recherche, etc.). À l’instar des cookies, ce cache n’est accessible que sur un seul vhost.

Bien sûr, les navigateurs qui ne supportent pas cette propriété utiliseront un chargement classique, de la même façon qu’ils le faisaient auparavant. Concrètement, il suffit généralement de remplacer votre appel à la méthode ajax de jQuery pour bénéficier du cache.

Ainsi $('#element').ajax('http://www.google.fr'); va devenir $('#element').cachedLoad('http://www.google.fr');. Vous pouvez également passer les paramètres habituels de la fonction load().

Enfin, pour supprimer volontairement le cache associé à un div, il vous suffit d’appeler la méthode cachedLoad() sans aucun paramètre.

Voilà, j’espère que ce petit plugin vous sera utile !

/**
	cachedLoad 1.0
	Pierre Quillery
    http://www.chosesafaire.fr/2010/01/cachedload-un-plugin-de-cache-pour-jquery/
 
	@param url string 
		Url à charger
	@param data object
		Paramètres à passer à la requête
	@param callback function 
		Fonction de callback à appeler éventuellement après le chargement
	
	Ce plugin permet d'utiliser la fonctionnalité html5 sessionStorage disponible 
	dans les navigateurs récents et ainsi éviter de multiplier les requêtes inutiles
	sur le serveur pour les bouts de page statiques (pied de page, formulaires de
	connexion etc.).
	
	*Si aucun paramètre n'est passé*, cela a pour effet de supprimer le cache
	associé à l'élément visé par le sélecteur.
	
	Voici la documentation "mozilla" :
	https://developer.mozilla.org/en/DOM/Storage#sessionStorage
	
	Pour les navigateurs n'implémentant pas cette fonctionnalité, on fait un 
	chargement classique.
	
	L'utilisation est calquée sur la méthode "load()" de jQuery
	(http://api.jquery.com/load/) : 
	
	$('#mon_div').cachedLoad('http://www.google.fr', function() { 
		alert('ok!'); 
	});
	
	$('#mon_div').cachedLoad('http://www.google.fr', {data:"data"}, function() { 
		alert('ok avec des paramètres!'); 
	});
	
	// Pour supprimer le cache
	$('#mon_div').cachedLoad();
	
	
	ATTENTION 
	==============================================================================
	Il est nécessaire que l'attribut ID du conteneur soit défini, car il est 
	utilisé pour définir une clé unique dans le tableau du sessionStorage. S'il 
	n'est pas	défini, on fera un appel Ajax classique et les données ne seront
	tout simplement pas mises en cache.
	==============================================================================
	
*/
jQuery.fn.cachedLoad = function(url, data, callback) {

	// Pour chaque appel du plugin ...
  return this.each(function() {
  	
  	// On récupère le contexte
		var self = $(this);
		var storage = window.sessionStorage; 

		// Est-ce qu'une URL a bien été passée en paramètre ?
		if(url) {
	
			// On autorise la syntaxe sans "data", comme jQuery
			if(typeof(data) == 'function') { callback = data; data = {}; }
			// Options par défaut
			data 			= data 			|| null;
			callback 	= callback 	|| function(){};
	
			// Si le sessionStorage est disponible et que l'élément a bien un id ...
			if(storage && self.attr('id') != '') {
		
				// On cherche le bout de page dans le cache
				var cache = storage['cachedLoad_' + self.attr('id')];

				// Le bout de page existait, on va l'afficher puis exécuter le callback
				if(cache) {
					self.html(cache);
					if(window.console && console.log) 
						console.log("cachedLoad : ", url);
					callback();
			
				// Le bout de page n'était pas en cache
				} else {
					// On le charge, on le met en cache, puis on appelle le callback
					self.load(url, data, function(r) {
						storage['cachedLoad_' + self.attr('id')] = r;
						callback();
					});
				}
	
			// Si le sessionStorage n'est pas disponible, on fait un appel classique
			// à la méthode load() de jQuery.
			} else {
				self.load(url, data, callback);
			}
		
		// Si aucune URL n'a été passée en paramètre, cela signifie que l'on
		// doit supprimer le cache
		} else {
		
			if(window.sessionStorage && self.attr('id') != '') {
				// On supprime l'entrée du cache pour forcer le futur rechargement
				delete storage['cachedLoad_' + self.attr('id')];
				if(window.console && console.log) 
					console.log("cachedLoad supprimé pour : ", self.attr('id'));
			}
			
		}
			
	});
};

Articles liés :

1. file-get-contents : Un plugin Wordpress pour inclure un fichier dans vos posts
2. LocalStorage, la suite logique de Google Gears ?

Java et Multithreading

Premièrement, il est important de comprendre le fonctionnement de l’interface Callable en Java ; une interface similaire à Runnable, à la différence près qu’un thread Callable renvoie une valeur lors de son exécution.

Ensuite, la classe utilitaire Executors, utile pour créer des pool de Threads, des pool de Threads périodique ou encore transformer un Runnable en Callable.

Enfin, l’interface Future, qui permet de stocker le futur résultat d’un appel asynchrone. Ce résultat peut être obtenu en appelant la méthode get() de votre objet, appel qui peut être bloquant si le résultat n’a pas encore été reçu. Il est possible de spécifier un timeout qui lèvera une exception si la durée de l’appel est supérieur.

Dans notre exemple, nous utiliserons un pool de taille fixe (nombre maximal de Threads défini), qui instanciera des Future stockant le résultat d’un calcul.

Mocking et Multithreading

C’est EasyMock qui sera utilisé, de par sa capacité à rendre l’exécution d’un Mock Threadsafe. Mockito permet aussi de créer des Mocks Threadsafe ; voici une brève comparaison entre EasyMock et Mockito, mais qui donne clairement l’avantage à Mockito du point de vue syntaxique !

Mise en pratique

Premièrement, la classe principale :

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class CalculMultiThread {
    private static final int THREAD_TIME_OUT = 10;
    private static final int POOL_SIZE = 5;

    private ExecutorService pool = null;

    public CalculMultiThread() {
        pool = Executors.newFixedThreadPool(POOL_SIZE);
    }

    public void setPool(ExecutorService pool) {
        this.pool = pool;
    }

    public void calculsParalleles(Integer op1, Integer op2, Integer op3, Integer op4) {
        final AdditionCallable additionCallable = new AdditionCallable();
        additionCallable.setOperande1(op1);
        additionCallable.setOperande2(op2);

        final SoustractionCallable soustractionCallable = new SoustractionCallable();
        soustractionCallable.setOperande1(op3);
        soustractionCallable.setOperande2(op4);

        final Future<Integer> additionFuture = pool.submit(additionCallable);
        final Future<Integer> soustractionFuture = pool.submit(soustractionCallable);

        try {
            final Integer resultatAddition = additionFuture.get(THREAD_TIME_OUT, TimeUnit.SECONDS);
            final Integer resultatSoustraction = soustractionFuture.get(THREAD_TIME_OUT, TimeUnit.SECONDS);

            System.out.println(op1 + " + " + op2 + " = " + resultatAddition);
            System.out.println(op3 + " + " + op4 + " = "  + resultatSoustraction);

        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        } catch (TimeoutException e) {
            e.printStackTrace();
        } finally {
            pool.shutdown();
        }
    }

    public static void main(String[] args) {
        CalculMultiThread calculMultiThread = new CalculMultiThread();
        calculMultiThread.calculsParalleles(5, 6, 8, 3);
    }
}

abstract class CalculCallable implements Callable<Integer> {
    private Integer operande1 = null;
    private Integer operande2 = null;

    public void setOperande1(Integer operande1) {
        this.operande1 = operande1;
    }

    public Integer getOperande1() {
        return this.operande1;
    }

    public void setOperande2(Integer operande2) {
        this.operande2 = operande2;
    }

    public Integer getOperande2() {
        return this.operande2;
    }
}

class AdditionCallable extends CalculCallable {
	public Integer call() throws Exception {
		return getOperande1() + getOperande2();
	}
}

class SoustractionCallable extends CalculCallable {
	public Integer call() throws Exception {
		return getOperande1() - getOperande2();
	}
}

Le résultat de l’opération :

5 + 6 = 11
8 - 3 = 5

Enfin, les tests :

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import org.easymock.EasyMock;
import org.junit.Before;
import org.junit.Test;

public class CalculMultiThreadTest {
    private ExecutorService executorServiceMock;
    private CalculMultiThread calculMultiThread;

    @Before
    public void setUp() throws Exception {
        executorServiceMock = EasyMock.createMock(ExecutorService.class);
        calculMultiThread = new CalculMultiThread();
        EasyMock.makeThreadSafe(executorServiceMock, true);
    }

    @SuppressWarnings("unchecked")
    @Test
    public void testCallTasksInParallel() throws Exception {
        calculMultiThread.setPool(executorServiceMock);

        Future<Integer> additionFutureMock = (Future<Integer>) EasyMock.createMock(Future.class);
        EasyMock.expect(additionFutureMock.get(EasyMock.anyLong(), EasyMock.isA(TimeUnit.class))).andReturn(11);
        EasyMock.replay(additionFutureMock);

        Future<Integer> soustractionFutureMock = (Future<Integer>) EasyMock.createMock(Future.class);
        EasyMock.expect(soustractionFutureMock.get(EasyMock.anyLong(), EasyMock.isA(TimeUnit.class))).andReturn(5);
        EasyMock.replay(soustractionFutureMock);

        EasyMock.expect(executorServiceMock.submit(EasyMock.isA(AdditionCallable.class))).andReturn(additionFutureMock);
        EasyMock.expect(executorServiceMock.submit(EasyMock.isA(SoustractionCallable.class))).andReturn(soustractionFutureMock);
        EasyMock.replay(executorServiceMock);

        calculMultiThread.calculsParalleles(5, 6, 8, 3);

        EasyMock.verify(additionFutureMock);
        EasyMock.verify(soustractionFutureMock);
        EasyMock.verify(executorServiceMock);
    }
}

Voilà, ce n’est pas plus compliqué de tester du code multithreadé. Pour plus d’informations, vous pouvez toujours consulter les liens qui suivent, merci !

• Source d’inspiration
• Comparaison des frameworks de Mock
• Java et applications concurrentes

Articles liés :

1. Mocks & Stubs : La suite
2. Le problème du Singleton
3. Mocks & Stubs : Leurres des Tests

Cet article fait partie d’une série sur le framework Ruby on Rails dont vous pouvez consulter le plan sur mon ancien site.

Il est également le dernier de la série de trois articles que j’ai publié sur l’implémentation de la couche Modèle de Ruby on Rails. Vous pouvez lire le premier article ou le second, si vous ne l’avez pas fait.

Les filtres (named_scope)

Ces filtres sont à mon avis une fonctionnalité très intéressante de Rails : ils permettent d’ajouter simplement un jeu de critères nommé à une requête SQL. Si on traduit le terme Anglais, il s’agit littéralement de « points de vue nommés » ; ce n’est pas très explicite, et c’est pourquoi je préfère le terme de « filtre » – il ne faut cependant pas les confondre avec les filtres de Contrôleur dont je parlais dans un précédent article.

Par exemple, imaginons que nous avons à notre disposition un magasin en ligne qui souhaite mettre en avant les produits qui sont les moins chers (dont le prix est entre 1 et 5 euros par exemple). Nous pourrions être tentés d’écrire ceci, par exemple :

Articles.find :all, :conditions => { :prix => [ 0 .. 5 ] }

Notez la syntaxe [ ... ], elle permet de spécifier un intervale de valeurs. L’inconvénient de cette façon de faire c’est que si par la suite nous voulons ajouter d’autres crtières de sélection (uniquement les articles de telle catégorie, uniquement ceux qui sont soldées, dont la date de péremption expire bientôt, etc.) nous allons devoir dupliquer ce critère … De plus, si notre client décide d’agrandir la gamme de prix, nous serions obligés de repasser sur tout notre code en risquant d’oublier quelque chose.

Nous pourrions bien sûr utiliser des constantes, ou des variables de classe, mais ça rendrait l’écriture de nos conditions encore plus longues et moins explicite – c’est là qu’interviennent les named_scope. Éditons la classe Article pour ajouter un filtre :

class Article < ActiveRecord::Base
  named_scode :pas_chers, :conditions => { :prix => [ 0 .. 5 ] }
end

Pour l’instant, nous n’avons fait que déplacer un peu de code du Contrôleur vers le Modèle, rien de transcendant – mais voilà ce que nous pouvons maintenant écrire :

@articles = Article.pas_chers.find :all, :conditions => { :rubrique_id => 2 }

Et voilà le travail : nous pouvons réutiliser et même chaîner des jeux de critères de sélection ! Attention toutefois à ne pas en abuser, même si c’est assez tentant : cela a un impact sur les performances qui doit rester maîtrisé.

Pour en savoir plus, je vous renvoie à la documentation de la méthode sur l’API ainsi qu’à un épisode des Railscasts de Ryan Bates (en Anglais).

Les fichiers de garniture (fixtures)

Les fichiers de garniture permettent d’ajouter facilement des données de test à votre application et vont donc en faciliter le développement : leur écriture peut se faire sous forme de fichier yaml ou csv. La première forme est la plus intéressante, car elle s’intègre mieux à Rails et permet même d’utiliser directement les mécanismes de relations entre les classes Modèles que nous voyions dans un précédent article.

Concrètement, tout se passe dans les fichiers qui sont générés automatiquement quand vous créez des Modèles à l’aide de la commande script/generate model .... Regardez dans le répertoire test/fixtures pour les retrouver. En reprenant l’exemple des classes que nous voyions dans l’article précédent, vous devriez ainsi trouver les fichiers articles.yml, taggables.yml, tags.yml et utilisateurs.yml.

Ouvrons dans un premier temps le premier fichier, articles.yml :

one:
  login: MyString
  mot_de_passe: MyString

two:
  login: MyString
  mot_de_passe: MyString

Comme vous pouvez le voir, le fait d’utiliser le générateur pour créer la classe de modèle Utilisateur a également eu pour effet de générer deux entrées dans ce fichier en renseignant directement les noms des colonnes que nous avions spécifié.

Notez également que chaque enregistrement possède déjà un identifiant (one et two) qui nous permettra d’y faire référence dans un autre fichier pour créer une relation !

Modifions un peu ce fichier pour créer des Utilisateur plus intéressants :

pierre:
  login: pierre
  mot_de_passe: mdp1

killian:
  login: killian
  mot_de_passe: mdp2

georges:
  login: georges
  mot_de_passe: mdp3

Nous pouvons maintenant utiliser chacun de ces enregistrements dans la garniture de la classe Article ! Ouvrons donc le fichier articles.yml :

one:
  titre: MyString
  contenu: MyText
  utilisateur_id: 1

two:
  titre: MyString
  contenu: MyText
  utilisateur_id: 1

Rails nous propose de changer la valeur de la colonne utilisateur_id, ce qui est tout à fait possible – cependant, puisque nous avons déjà défini des relations entre ces deux classes, nous allons pouvoir nous passer de cette étape et réécrire le contenu de ce fichier de la façon suivante :

article1:
  titre: "Mon premier article"
  contenu: "Contenu de mon premier article"
  utilisateur: pierre

article2:
  titre: "Mon deuxième article"
  contenu: "Contenu de mon deuxième article"
  utilisateur: killian

article3:
  titre: "Mon troisième article"
  contenu: "Contenu de mon troisième article"
  utilisateur: pierre

Rails comprendra tout seul que l’utilisateur pierre auquel nous faisons référence a été défini dans le fichier utilisateurs.yml.

Nous pouvons maintenant vider notre base de développement (rake db:reset)pour la remplir avec ces quelques enregistrements, à l’aide de la commande rake db:fixtures:load. Ouvrez maintenant une console Rails, (script/console) et constatez que les enregistrements ont bien été créés dans la base :

>> Utilisateur.find :all
=> [#<Utilisateur id: 134130964, login: "killian", mot_de_passe: "mdp2",
created_at: "2009-12-23 13:26:49", updated_at: "2009-12-23 13:26:49">,
#<Utilisateur id: 219077049, login: "georges", mot_de_passe: "mdp3",
created_at: "2009-12-23 13:26:49", updated_at: "2009-12-23 13:26:49">,
#<Utilisateur id: 362712307, login: "pierre", mot_de_passe: "mdp1",
created_at: "2009-12-23 13:26:49", updated_at: "2009-12-23 13:26:49">]

>> Article.find :all
=> [#<Article id: 151089403, titre: "Mon troisième article",
contenu: "Contenu de mon troisième article", utilisateur_id: 362712307,
created_at: "2009-12-23 13:26:50", updated_at: "2009-12-23 13:26:50">,
#<Article id: 655299028, titre: "Mon premier article",
contenu: "Contenu de mon premier article", utilisateur_id: 362712307,
created_at: "2009-12-23 13:26:50", updated_at: "2009-12-23 13:26:50">,
.#<Article id: 1040597104, titre: "Mon deuxième article",
contenu: "Contenu de mon deuxième article", utilisateur_id: 134130964,
created_at: "2009-12-23 13:26:50", updated_at: "2009-12-23 13:26:50">]

Vous remarquerez que les identifiants des enregistrements créés par ce biais ne commencent jamais par 1, ce qui permet de les distinguer facilement des enregistrements standards et ce qui évitent qu’ils perturbent vos tests manuels.

Si vous voulez tagger un article dans les garnitures, c’est un peu plus sophistiqué, car il faut indiquer à Rails que vous passez par une table intermédiaire à cause de l’utilisation du système has_many :through ; la démarche reste cependant la même : voyez directement dans la documentation pour en apprendre plus.

En guise de conclusion, notez que les fixtures ne sont pas une réponse à toutes les situations. Par exemple, c’est généralement une mauvaise idée de s’en servir pour placer des données nécessaires au bon fonctionnement de l’application : les données que vous y placerez doivent être réservées à vos tests fonctionnels & unitaires.

Si vous avez besoin de mettre en place des données de base pour votre application en production, utilisez le fichier db/seeds.rb. Vous pourrez ensuite exécuter les commandes qu’il contient avec la commande rake db:setup.

La suite au prochain épisode !

Cet article était le dernier de notre série consacrée à la couche Modèle de Rails : aussi dès la semaine prochaine (si tout va bien ) nous entamerons une toute nouvelle séquence qui concernera l’implémentation des ressources et des formulaires dans notre framework préféré.

Articles liés :

1. La couche Modèle de Rails (Partie 2)
2. La couche Modèle de Rails (Partie 1)

Configuration des base de données dans Rails

Comme vous l’avez sans doute remarqué dans le précédent article, nous avons directement commencé à travailler avec la base de données sans pour autant avoir eu besoin de configurer quoi que ce soit au niveau de l’application. En effet, ainsi que je le décrivais déjà ici, Rails se repose par défaut sur une base Sqlite, ce qui permet de s’affranchir de configuration et rentrer directement dans le vif du sujet.

La configuration concernant les bases de données est placée dans le fichier config/database.yml. Comme vous pouvez le voir, on y trouve 3 zones qui correspondent à la configuration de chaque environnement (dev, preprod et prod). L’intérêt de ce fonctionnement est qu’il est très souple à l’usage : pour développer vous aurez rarement besoin d’une base MySql, alors qu’en production, c’est une nécessité.

# SQLite version 3.x
#   gem install sqlite3-ruby (not necessary on OS X Leopard)
development:
  adapter: sqlite3
  # Emplacement du fichier où se trouve la base
  database: db/development.sqlite3
  # Nombre de connexion dans le pool
  pool: 5
  timeout: 5000

# ...

Notons que MySQL n’est pas le seul SGBD supporté par Rails : il en est de même pour PostgreSQL, DB2, SQL Server, Oracle, Sybase, Firebird, etc.

Prenons l’exemple de MySQL, et changeons la configuration pour nous connecter à une base MySQL correspondant à notre application en production :

# ...

production:
  adapter: mysql
  # Encodage du client
  encoding: utf8
  # Nom de la base à laquelle se connecter
  database: monapplication_prod
  pool: 5
  username: monnomdutilisateur
  password: monmotdepasse
  # Si la base se trouve sur la machine locale ...
  socket: /var/run/mysqld/mysql.sock
  # ... Ou si la base se trouve ailleurs
  host: serveurbdd.monapplication.com

Interaction avec les bases de données avec la ligne de commande

Nous avons vu dans le précédent article comment utiliser les migrations pour interagir avec les bases de données via la ligne de commande Rails. Voici quelques autres commandes qui vous permettront de tester tout ça à loisir :

• rake db:create → Créer la base de donnée
• rake db:destroy → Détruire la base de données

Notez que ces commandes, comme toutes les opérations en ligne de commande de Rails, sont sensibles au contexte pour le choix de l’environnement à affecter : par défaut, vous travaillez avec l’environnement de développement. Pour changer ce comportement, il vous faut changer la valeur de la variable d’environnement RAILS_ENV en lui donnant le nom de l’environnement de votre choix.

Ainsi vous écrirez par exemple la commande suivante pour supprimer le contenu de la base de production :

RAILS_ENV=production rake db:destroy

Sélection, Modification et Suppression d’élément

Utilisation de la console Rails

Ruby on Rails intègre une console interactive qui est un lieu d’expérimentation privilégié : vous pouvez directement créer des objets persistants en base, tester un bout de code, une fonction, etc. Nous allons l’utiliser pour la suite du tutorial, car cela nous évitera d’avoir à nous soucier des autres couches. Pour la démarrer, rien de plus simple :

script/console

Vous entrez maintenant dans la console interactive, tapez quit pour en sortir à tout moment ! Notez enfin que l’invite de commande commence toujours par les caractères >> alors que les retours de ruby sont préfixés d’une flèche =>.

Mise en place de notre projet de travail

Voici quelques commandes qui vous nous permettre de mettre en place un projet pour tester un peu les possibilités offertes en ce qui concerne les opérations simples de CRUD sur lesquelles nous allons nous attarder aujourd’hui.

rails appli_de_test
cd appli_de_test
script/generate model Utilisateur login:string mot_de_passe:string
script/generate model Article titre:string contenu:text utilisateur_id:integer
script/generate model Tag libelle:string --skip-timestamps
script/generate model Taggable tag_id:integer article_id:integer --skip-timestamps

Nous allons créer, comme vous l’avez compris un blog minimaliste : un Utilisateur possède des Articles. Les Articles partagent un ou plusieurs Tags via la relation Taggable.

Il ne nous reste plus qu’à éditer les fichiers de classes correspondants que vous trouverez dans le répertoire app/models pour exprimer explicitement les relations qui lient ces éléments entre eux :

# app/models/utilisateur.rb
class Utilisateur < ActiveRecord::Base
  has_many :articles
end

# app/models/article.rb
class Article < ActiveRecord::Base
  belongs_to :utilisateur
  has_many :taggables
  has_many :tags, :through => :taggables
end

# app/models/taggable.rb
class Taggable < ActiveRecord::Base
  belongs_to :article
  belongs_to :tag
end

# app/models/tag.rb
class Tag < ActiveRecord::Base
  has_many :taggables
  has_many :articles, :through => :taggables

  # Ce champ est obligatoire, on force donc sa présence
  validates_presence_of :libelle
end

Maintenant, il ne nous reste plus qu’à mettre en place la structure de la base de données, à l’aide de la commande rake db:migrate puis à nous connecter à la console de Rails pour commencer nos essais : script/console

Création d’élément

Précisons en guise de préambule que cet aperçu des possibilités qui vous sont offertes par Rails et Active Record (classe qui s’occupe spécifiquement de la persistence des données en base) est vraiment très superficiel ; je ne saurais trop vous conseiller de vous référer à la documentation d’Active Record pour apprendre réellement à vous en servir .

Nous allons tout d’abord créer des Tags à l’aide de la méthode create(). Cette méthode va instancier un objet Tag et créer directement l’enregistrement en base (si la validation s’est bien déroulée).

>> t = Tag.create
=> #<Tag id: nil, libelle: nil>

Ah, nous remarquons le Tag n’a pas d’id (nil signifie null en PHP) ; cela signifie qu’il n’est pas présent en base – or il devrait l’être, puisque c’est ce que nous attendons de la commande create() …

Une erreur s’est produite à cause de la validation que nous avons ajouté dans la classe Tag : j’ai volontairement omis de préciser le champ libelle et l’enregistrement n’a pu être effectué. C’est ce mécanisme qui nous permettra de faciliter la validation des formulaires, ainsi que nous le verrons dans un prochain article.

Rails nous indique en fait dans la variable errors de l’objet t la liste des erreurs qui se sont produites et qui empêchent la validation et donc l’enregistrement de l’élément :

>> t = Tag.create
=> #<Tag id: nil, libelle: nil>
>> t.errors
=> #<ActiveRecord::Errors:0x7fd366f44020 @errors=#<OrderedHash
  {"libelle"=>[#<ActiveRecord::Error:0x7fd366f42f90 @attribute=:libelle,
  @type=:blank, @options={}, @message=:blank, @base=#<Tag id: nil,
  libelle: nil>>]}>, @base=#<Tag id: nil, libelle: nil>>

Le message n’est pas forcément très lisible présenté comme ça, mais nous apprenons ainsi qu’il s’agit d’une erreur qui concerne le champ libelle et qu’elle a le type :blank. Le mécanisme de validation de formulaire de Rails rendra ce tableau très facile à exploiter pour nous par la suite, même s’il n’a pas l’air très avenant vu sous cet angle !

Essayons maintenant de reprendre la saisie des Tags en évitant de provoquer des erreurs :

>> Tag.create :libelle => "Rock"
=> #<Tag id: 1, libelle: "Rock">
>> Tag.create :libelle => "Folk"
=> #<Tag id: 2, libelle: "Folk">
>> Tag.create :libelle => "Soul"
=> #<Tag id: 3, libelle: "Soul">
>> Tag.create :libelle => "Funk"
=> #<Tag id: 4, libelle: "Funk">

Ce coup-ci, il est clair que tout se passe bien : les enregistrements se voient directement attribuer un id numérique, ce qui signifie qu’ils sont maintenant présents en base.

Sélection d’éléments

Maintenant que la base est peuplée de quelques éléments, nous pouvons nous intéresser aux méthodes qui nous permettent de retrouver ces mêmes éléments. Tout passe à vrai dire par la méthode de classe find qui est disponible pour chaque classe de modèle.

Ainsi, pour sélectionner une collection d’éléments, nous utilisons la variante find :all, en voici un exemple :

>> Tag.find :all
=> [#<Tag id: 1, libelle: "Rock">, #<Tag id: 2, libelle: "Folk">, #<Tag id: 3, libelle: "Soul">, #<Tag id: 4, libelle: "Funk">]

Notez que dans le retour qui est fait, Rails nous renvoie bien une collection d’éléments qu’il a placé dans un tableau ([ ... ]) ; comme en Javascript, on emploie en Ruby les crochets pour écrire un tableau.

Essayons maintenant d’ajouter une condition à notre sélection – plusieurs syntaxes sont disponibles, voici celle qui permet de créer une sorte de requête préparée qui prend la forme d’un tableau. Les ? dans la requête SQL sont ainsi remplacés par les valeurs entrées dans les index suivant. Ici nous recherchons par exemple les Tags qui commencent par la lettre F.

>> Tag.find :all, :conditions => [ 'libelle like ?', 'F%' ]
=> [#<Tag id: 2, libelle: "Folk">, #<Tag id: 4, libelle: "Funk">]

Voyons maintenant comment sélectionner un élément unique dans la base ; pour cela, on emploie la version find :first de la méthode :

>> Tag.find :first, 1
=> #<Tag id: 1, libelle: "Rock">

Dans le cas présent, Rails a bien renvoyé un élément unique, et non un tableau, ainsi que c’était le cas précédemment. On aurait éventuellement pu omettre le :first, c’est en fait la méthode utilisée par Rails si on ne précise rien.

Nous allons maintenant voir une autre façon d’écrire les conditions : plutôt que de passer un tableau, il est également possible de passer un simple hash ({ ... }) – il s’agit d’une sorte de tableau associatif :

>> Tag.find :first, :conditions => { :libelle => 'Rock' }
=> #<Tag id: 1, libelle: "Rock">

Voilà les bases de ce qu’il est possible de faire pour sélectionner des éléments ; vous trouverez ici le détail des différentes options supportées par la méthode find, elles sont nombreuses. Vous pouvez également regarder ce screencast qui fait une démonstration des possibilités offertes par cette méthode.

Modification d’un élément

Maintenant que vous savez retrouver un élément, il serait utile de savoir le modifier puis le sauvegarder ; voici comment faire en employant assez logiquement la méthode save :

>> t = Tag.find :first, 1
=> #<Tag id: 1, libelle: "Rock">
>> t.libelle = "Rock'n'Roll"
=> "Rock'n'Roll"
>> t.save
=> true

Je sélectionne ainsi l’élément « Rock », que je désire modifier en « Rock’n'Roll ». Il me suffit de changer la valeur du champ « libelle », puis de sauvegarder. Notez que la méthode save retourne une variable qui va nous permettre de savoir que l’enregistrement a bien été effectué, s’il a correctement passé la validation. Retrouvez ici la documentation concernant cette méthode.

Voici un exemple de modification qui va échouer :

>> t = Tag.find 2
=> #<Tag id: 2, libelle: "Folk">
>> t.libelle = ""
=> ""
>> t.save
=> false
>> t.errors
=> #<ActiveRecord::Errors:0x7f9f6d187d60 @errors=#<OrderedHash
  {"libelle"=>[#<ActiveRecord::Error:0x7f9f6d185510 @attribute=:libelle,
  @type=:blank, @options={}, @message=:blank, @base=#<Tag id: 2,
  libelle: "">>]}>, @base=#<Tag id: 2, libelle: "">>

Comme avec la méthode create que nous voyions tout à l’heure, il est toujours possible d’accéder aux messages de validation. Il nous est toutefois possible de court-circuiter la validation si nous sommes dans un environnement contrôlé, ce qui permet d’accélérer le traitement, grâce à la méthode save!.

Suppression d’un élément

Dernière partie, et non la moins importante de notre passage en revue du CRUD le plus basique en Rails, la destruction d’un élément. Voilà comment s’y prendre, grâce à la méthode destroy :

>> t = Tag.find :first, :conditions => {:id => 1}
=> #<Tag id: 1, libelle: "Rock'n'Roll">
>> t.destroy
=> #<Tag id: 1, libelle: "Rock'n'Roll">
>> Tag.find :first, :conditions => {:id => 1}
=> nil

Il est important de noter que la fonction destroy retourne l’élément supprimé en cas de succès, ce qui s’avère souvent très utile.

Créons des relations entre les objets

Maintenant que nous savons interagir avec nos Modèles, il nous reste à voir comment créer des relations entre eux ; nous allons ainsi créer un Utilisateur et lui ajouter plusieurs Articles, ce qui nous permettra de voir le fonctionnement de la relation 1 à plusieurs. Dans un second temps, nous verrons comment assigner des Tags à un Article donnée en passant par la relation plusieurs à plusieurs.

Utiliser la relation Un à Plusieurs

Voici quelques commandes maintenant connues qui vont nous permettre de créer quelques enregistrements que nous allons utiliser par la suite.

>> util1 = Utilisateur.create :login => "utilisateur1", :mot_de_passe => "mdp1"
=> #<Utilisateur id: 1, login: "utilisateur1", mot_de_passe: "mdp1",
  created_at: "2009-12-11 17:07:08", updated_at: "2009-12-11 17:07:08">
>> util2 = Utilisateur.create :login => "utilisateur2", :mot_de_passe => "mdp2"
=> #<Utilisateur id: 2, login: "utilisateur2", mot_de_passe: "mdp2",
  created_at: "2009-12-11 17:07:21", updated_at: "2009-12-11 17:07:21">

>> arti1 = Article.create :titre => "Titre de mon premier article",
  :contenu => "Pas de contenu pour le moment"
=> #<Article id: 1, titre: "Titre de mon premier article",
  contenu: "Pas de contenu pour le moment", utilisateur_id: nil,
  created_at: "2009-12-11 17:08:11", updated_at: "2009-12-11 17:08:11">
>> arti2 = Article.create :titre => "Titre de mon second article",
  :contenu => "Pas de contenu pour le moment"
=> #<Article id: 2, titre: "Titre de mon second article",
  contenu: "Pas de contenu pour le moment", utilisateur_id: nil,
  created_at: "2009-12-11 17:08:28", updated_at: "2009-12-11 17:08:28">
>> arti3 = Article.create :titre => "Titre de mon troisième article",
  :contenu => "Pas de contenu pour le moment"
=> #<Article id: 3, titre: "Titre de mon troisième article",
  contenu: "Pas de contenu pour le moment", utilisateur_id: nil,
  created_at: "2009-12-11 17:08:42", updated_at: "2009-12-11 17:08:42">

Comment changer le rédacteur du premier Article pour dire qu’il est en fait le premier Utilisateur ? Rien de plus simple :

>> arti1.utilisateur = util1
=> #<Utilisateur id: 1, login: "utilisateur1", mot_de_passe: "mdp1",
  created_at: "2009-12-11 17:07:08", updated_at: "2009-12-11 17:07:08">
>> arti1.save
=> true
>> arti1
=> #<Article id: 1, titre: "Titre de mon premier article",
  contenu: "Pas de contenu pour le moment", utilisateur_id: 1,
  created_at: "2009-12-11 17:08:11", updated_at: "2009-12-11 17:10:41">

Si nous avions voulu exploiter la relation dans le sens inverse, il nous aurait fallu énoncer les choses différemment : en effet un Article n’a qu’un seul et unique Utilisateur dans notre exemple – alors qu’un Utilisateur peut avoir écrit un nombre indéfini d’Articles.

Rails nous donne donc accès à un tableau dans le lequel il nous suffit d’ajouter les Articles de notre choix à l’Utilisateur qui est leur auteur. Disons que le deuxième Utilisateur a écrit les deux derniers articles :

>> util2.articles = [ arti2, arti3 ]
=> [#<Article id: 2, titre: "Titre de mon second article",
  contenu: "Pas de contenu pour le moment", utilisateur_id: 2,
  created_at: "2009-12-11 17:08:28", updated_at: "2009-12-11 17:14:41">,
  #<Article id: 3, titre: "Titre de mon troisième article",
  contenu: "Pas de contenu pour le moment", utilisateur_id: 2,
  created_at: "2009-12-11 17:08:42", updated_at: "2009-12-11 17:14:41">]
>> util2.save
=> true
>> util2
=> #<Utilisateur id: 2, login: "utilisateur2", mot_de_passe: "mdp2",
  created_at: "2009-12-11 17:07:21", updated_at: "2009-12-11 17:07:21">

Et voilà pour la relation Un à Plusieurs ; comme vous le voyez, le fonctionnement de Rails à ce sujet est assez intuitif et logique.

Utiliser la relation Plusieurs à Plusieurs

Nous allons maintenant ajouter les tags que nous avons déjà employé précédemment pour tagguer nos Articles. Rails fait la plus grosse partie de notre travail grâce à la relation has_many :through que nous avons défini dans les classes Article et Tag : nous pouvons faire abstraction de la classe Taggable avec laquelle notre framework se chargera d’interagir.

Commençons par ajouter deux Tags à notre premier article :

>> arti1.tags << Tag.find(:first, :conditions => { :libelle => "Folk" })
=> [#<Tag id: 2, libelle: "Folk">]
>> arti1.tags << Tag.find(:first, :conditions => { :libelle => "Funk" })
=> [#<Tag id: 2, libelle: "Folk">, #<Tag id: 4, libelle: "Funk">]
>> arti1.tags
=> [#<Tag id: 2, libelle: "Folk">, #<Tag id: 4, libelle: "Funk">]

Notez que j’utilise une syntaxe différente pour interagir avec le tableau des tags de l’Article ; l’opérateur << peut se lire comme : « ajoute l’élément suivant à ce tableau » ; il s’agit d’un équivalent du array_push() de PHP ou du push() de Javascript.

Ajoutons encore quelques Tags à un autre Article et regardons le contenu de la table contenant les Taggables, avec lesquels nous ne sommes pas directement intervenus, pour constater que Rails a fait lui-même les associations nécessaires pour nous permettre de nous abstraire de cette table de jointure.

>> arti2.tags = Tag.find(:all)
=> [#<Tag id: 2, libelle: "Folk">, #<Tag id: 3, libelle: "Soul">,
  #<Tag id: 4, libelle: "Funk">]
>> Taggable.find :all
=> [#<Taggable id: 1, tag_id: 2, article_id: 1>,
  #<Taggable id: 2, tag_id: 4, article_id: 1>,
  #<Taggable id: 3, tag_id: 2, article_id: 2>,
  #<Taggable id: 4, tag_id: 3, article_id: 2>,
  #<Taggable id: 5, tag_id: 4, article_id: 2>]

Voilà, c’est tout pour aujourd’hui ! Dans quelques temps, nous verrons la suite (et a priori la fin) de notre programme initial sur la couche Modèle de Rails, avec les garnitures (fixtures) & les filtres. En attendant, n’hésitez pas à essayer de refaire ce tutoriel chez vous, c’est tout son intérêt , et laissez un commentaire si vous rencontrez un problème.

Articles liés :

1. La couche Modèle de Rails (Partie 3)
2. La couche Modèle de Rails (Partie 1)

Tout d’abord, un petit disclaimer s’impose par rapport au contenu de cet article : il s’agit de la suite d’une série d’articles que j’avais commencé sur mon précédent blog sans aller jusqu’au bout. Je ne pense pas reprendre les anciens articles sur ce blog-ci, ce qui n’aurait pas beaucoup de sens dans un premier temps – je vous invite donc à aller consulter la page de présentation de mon projet ainsi que les premiers articles sur l’ancien site.

Un Modèle ?

Le Modèle est, comme nous l’avons précédemment, une des trois couches du modèles MVC. Il s’agit de celle qui est en charge de permettre l’enregistrement et la recherche de données. Typiquement, on utilise pour cela une classe dite d’ORM, de mapping objet-relationnel, qui va nous permettre de nous abstraire d’un SGBD particulier tout en s’intégrant mieux dans un ensemble de classes.

L’idée est de réduire au maximum la distance qui sépare la base de données (l’implémentation du stockage de données) des objets métiers de notre application (un Client, un Article, un Blog, un Commentaire, etc.). C’est également dans la couche Modèle que nous allons définir facilement les relations entre ces derniers (un Article a plusieurs Commentaires, etc.) ainsi que la validation des données (la date de naissance d’un utilisateur donné doit toujours être sous la forme jj/mm/aaaa, etc.).

Créons une nouvelle classe de Modèle à l’aide des Migrations

Tout d’abord, qu’est ce qu’une migration ? Il s’agit d’un fichier qui va contenir la définition d’une ou plusieurs tables ainsi que des champs qui les composent. Ils peuvent être créés soit automatiquement, (lorsque vous ajoutez une classe métier) soit par un plugin … Vous pouvez également en générer à tout moment.

L’idée est de placer dans un fichier texte facile à lire et à éditer la structure de votre base de données. Rails s’occupera ensuite de générer les commandes SQL qui correspondent dans la base correspondant à votre environnement courant (nous verrons cela plus loin). Vous pouvez ainsi facilement versionner votre base.

Créons donc un classe Modèle de test à l’aide de la console Rails. Comme vous le voyez, je précise immédiatement les champs que je connais de ce Modèle : ils seront ajoutés automatiquement par Rails dans le fichier de migration correspondant que nous complèterons manuellement tout à l’heure.

script/generate model Article titre:string date_publication:datetime contenu:text timestamps

Ça y est : quelques fichiers ont été créés, notamment app/models/article.rb qui est la classe de notre Modèle à propremment parler, et qui ne contient rien pour l’instant et db/migrate/xxxx_create_article.rb, notre Migration.

Voyons maintenant le contenu de ce deuxième fichier :

class CreateArticles < ActiveRecord::Migration

  # Méthode appelée pour mettre en place la migration
  def self.up
    create_table :articles do |t|
      t.string :titre
      t.text :contenu
      t.datetime :date_publication

      # Va créer un champ auteur_id que nous utiliserons un peu plus loin
      t.references :auteur

      # Ajout automatique de champs tels que created_at, modified_at, etc.
      # Ces champs seront ensuite gérés par Rails automatiquement.
      t.timestamps
    end
  end

  # Méthode permettant d'enlever la migration au besoin
  def self.down
    drop_table :articles
  end
end

Nous pouvons éditer le fichier pour ajouter éventuellement des champs supplémentaires puis déclencher la migration en utilisant la ligne de commande Rails. Nous pourrons alors utiliser le fichier de Modèle et poursuivre notre application.

rake db:migrate

Validation dans le Modèle

Nous allons maintenant travailler avec la classe Modèle qui se trouve dans le répertoire app/models et ajouter du code pour faciliter la validation des champs qui s’y trouvent. Cela signifie que nous pourrons ainsi nous assurer par exemple du bon formattage d’un email, d’une date de naissance, de la présence d’un titre etc.

Cette validation empêchera par défaut toute création d’enregistrement ou mise à jour. Elle ajoutera le cas échéant des messages au modèle (personnalisables et même disponibles en plusieurs langues via l’internationalisation du framework) que vous pourrez simplement montrer à l’utilisateur pour lui permettre de corriger facilement sa saisie.

class Article < ActiveRecord::Base
  # Le titre de l'article est obligatoire (il ne doit pas être vide)
  validate_presence_of :titre

  # Le titre ne devrait pas être trop court ...
  validates_length_of :titre, :minimum => 30

  # etc .
end

Voici une page où vous trouverez toutes les méthodes de validation à votre disposition, les méthodes par défaut couvrent une bonne partie des besoins les plus évidents.

Nous verrons dans le prochain article comment exploiter efficacement ces messages de validation pour les afficher à l’internaute lors de sa saisie.

Créons des Relations

La création de relations est une partie intéressante des possibilités que Rails vous offre pour la couche Modèle : vous pouvez ainsi exprimer directement les principaux types de relations dont vous avez besoin pour reproduire tout schéma de base dans votre application.

Précisons d’abord que pour fonctionner, Rails a tout de même besoin que vous respectiez ses propres convention de nommage des champs pour lui permettre de retrouver ses petits et inférer ce que vous voulez faire. Ainsi, les champs de clés étrangères seront toujours nommées champ_id.

Je vais maintenant présenter les principaux types de relations disponibles, mais toutes ces méthodes sont très personnalisables, voyez dans la documentation pour en apprendre plus à leur sujet.

Une à Plusieurs

Un des cas le plus fréquent est la relation Une à Plusieurs : un Auteur a plusieurs Articles, un Article a plusieurs Commentaires, etc. Voici comment l’écrire dans les classes e Modèle (je pars du principe que les modèles correspondants ont été créés et migrés vers la base) :

# Fichier app/models/commentaire.rb
class Commentaire < ActiveRecord::Base
  # C'est cette table qui contient la clé étrangère article_id,
  # on écrit donc belongs_to puis le nom du Modèle à lier au singulier
  belongs_to :article
end

# Fichier app/models/article.rb
class Article < ActiveRecord::Base
  # Deuxième côté de la relation, on écrit has_many puis le
  # nom du Modèle au pluriel.
  has_many :commentaires
end

Une à Une

Moins fréquent, vous pouvez restreindre cette relation pour créer une relation Une à Une en changeant le has_many par un has_one, comme dans cet exemple :

# Fichier app/models/utilisateur.rb
class Utilisateur < ActiveRecord::Base
  # C'est cette table qui contient la clé étrangère profil_id
  belongs_to :profil
end

# Fichier app/models/profil.rb
class Profil < ActiveRecord::Base
  # Deuxième côté de la relation, on écrit has_many puis le
  # nom du Modèle au singulier.
  has_many :utilisateur
end

Plusieurs à Plusieurs et Relations Composites

Vous trouverez sur Internet de nombreux tutoriaux qui vous présenteront l’emploi de la technique dite du habtm ou has_and_belongs_to ; je ferais pour ma part l’impasse sur cette dernière qui est maintenant globalement dépréciée et qui ne devrait plus être utilisée dans la plupart des cas.

Voici donc la bonne façon de voir les choses pour créer une relation Plusieurs à Plusieurs viable, c’est à dire grâce au has_many :through :

# Fichier app/models/utilisateur.rb
class Utilisateur < ActiveRecord::Base
  has_many :abonnements
  has_many :magazines, :through => :abonnements
end

# Fichier app/models/abonnement.rb
class Abonnement < ActiveRecord::Base
  # Notez qu'on emploie dans cet objet deux clés étrangères
  belongs_to :utilisateur
  belongs_to :magazine
end

class Magazine < ActiveRecord::Base
  has_many :abonnements
  has_many :utilisateurs, :through => :abonnements
end

Rien ne vous empêche d’ajouter des champs supplémentaires à votre objet Abonnement si vous souhaitez enrichir la relation ; on pourrait imaginer enregistrer la durée de l’abonnement par exemple. Ce n’était pas possible avec l’ancienne technique (habtm), et c’est une des raisons pour laquelle elle tombe petit à petit en désuétude.

Vous pouvez, sur le même principe, créer des relations composites (ou polymorphiques) qui pourront vous servir à factoriser pas mal de code en créeant une interface commune auxquels des Modèles de différents types pourront s’accrocher. C’est un peu complexe à expliquer, mais un exemple vaut mieux qu’un long discours :

class Coordonnee < ActiveRecord::Base
  # Il faut deux champs supplémentaires dans la table coordonnees :
  # - localisable_id, un entier
  # - localisable_type, une chaîne
  # => Utilisez la syntaxe suivante dans la Migration :
  #    t.references :localisable, :polymorphic => true
  belongs_to :localisable, :polymorphic => true
end

class Utilisateur < ActiveRecord::Base
  has_many :localisations, :as => :localisable
end

class Societe < ActiveRecord::Base
  has_many :localisations, :as => :localisable
end

Grâce à cette syntaxe, les Utilisateurs et les Societes partagent la possibilité d’avoir un objet Coordonnees qui leur est lié, ce qui serait plus complexe à mettre en place sinon. Nous pourrions facilement faire évoluer ce modèle au besoin, c’est ce qui fait sa force.

Dans quelques jours, nous verrons la suite de notre programme sur les Modèles dans Rails en parlant des différents types de base de données disponibles et leur configuration, des requêtes préparées, etc. Voir l’article suivant !

Articles liés :

1. La couche Modèle de Rails (Partie 3)
2. La couche Modèle de Rails (Partie 2)

Le problème

Imaginons un composant Service, une quelconque classe métier. Dans une de ses méthodes, la classe Service fait appel à un autre composant, nommé par exemple Counter ; ce dernier est un simple compteur qui incrémente sa valeur à chaque appel d’un service. Pour avoir un compteur commun à tous les services, il doit en exister une instance unique, partagée par tous les composants de type Service.

Ainsi, voici un exemple d’implémentation :

class Counter {
    private static final Counter instance = new Counter();
    private int count = 0;

    private Counter() {}

    public static Counter getInstance() {
        return instance;
    }

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

class Service {
    public void execute() {
        // ...
        Counter.getInstance().increment();
    }
}

L’implémentation semble correcte, un test unitaire appelant le service peut être écrit afin d’en vérifier le comportement. Imaginons maintenant que :

• Un grand nombre d’autres services utilise ce compteur ;
• L’appel à l’incrémentation du compteur soit très complexe, faisant appel à des webservices / se connectant à une base de données / lisant un fichier du système ;
• Plusieurs tests unitaires, pouvant même être lancés simultanément, ont besoin d’un compteur « remis à zéro ».

Que faire ?

Votre service est complètement dépendant de la classe Counter. Ecrire une méthode qui réinitialise le Singleton ? Rajouter des conditions dans la méthode du Singleton pour éviter les opérations trop importantes en cas de test ? Les tests unitaires n’ont pas à interférer votre code métier, qui réciproquement ne doit pas changer pour s’adapter aux tests. Ce qui importe dans ce test, c’est de vérifier le fonctionnement du service, et non l’appel au compteur ; comment mocker le compteur si celui-ci est un Singleton et crée lui-même son instance ?

Une solution au problème est l’injection de dépendances. Votre application (ou plutôt le container IoC) va se charger d’instancier l’unique compteur et de l’injecter dans chacun des services. Le processus peut-être fait manuellement, mais sera bien plus simple à mettre en place avec un framework spécialisé comme Spring ou Guice. Voici un exemple avec Spring :

interface Counter() {
    void increment();
    int getCount();
}

class ComplexCounter implements Counter {
    private int count = 0;

    public Counter() {}

    public void increment() {
        // Beaucoup de choses compliquées et très lourdes, assez longues à exécuter (le temps d'aller boire un café)
        count++;
    }

    public int getCount() {
        return count;
    }
}

class Service {
    private Counter counter;

    public Service(Counter counter) {
        this.counter = counter;
    }

    public void execute() {
        // ...
        counter.increment();
    }
}

<bean id="counter" class="fr.chosesafaire.singleton.ComplexCounter" />
<bean id="service">
    <constructor-arg ref="counter" />
</bean>
<bean id="otherService">
     <constructor-arg ref="counter" />
</bean>

Ainsi votre instance de compteur reste un Singleton au sens conceptuel du terme (instance unique partagée par les autres composants), mais la classe Counter ne gère plus elle-même son instance. L’avantage est de pouvoir tester désormais le service en mockant le compteur, et éviter la liste d’ennuis énoncée précédemment (avec jMock) :

Mockery context = new Mockery();

public void testService() {
    final Counter counter = context.mock(Counter.class);
    context.checking(new Expectations() {{
        oneOf(counter).increment();
    }});

    Service service = new Service(counter);
    service.execute();

    // Assertions ...
    context.assertIsSatisfied();
}

On s’attend seulement (Expectations) à ce que la méthode increment du compteur soit appelée, et peu importe son réel fonctionnement, vu que seul le Service doit être testé !

Que pensez-vous de cette solution à propos du Singleton ? Comment faîtes-vous pour tester vos classes Singleton ?

Voici quelques références :

• Le guide de l’écriture d’un code testable, par des développeurs de Google
• Injected Singleton

Articles liés :

1. Mocks et Multithreading
2. Easyb, Behavior Driven Development

L’objectif de ce tutoriel est d’implémenter un petit moteur de recherche Lucene en Scala, en joignant les deux bouts grâce à Spring. Etant débutant en Scala (j’étais jusqu’à présent plutôt du côté Groovy de la force), j’espère en avoir tiré tous les avantages dans cet exemple. Si certaines parties peuvent être écrites de façon plus fonctionnelle et moins Javaesque, n’hésitez pas à laisser un commentaire.

Les sources sont normalement assez commentées (en anglais) pour être compréhensibles ; il n’y a de toute façon que trois fichiers :

• pom.xml qui est le fichier « projet » pour Maven ;
• applicationContext.xml, le fichier de configuration Spring ;
• Main.scala, le fichier où sont rassemblées toutes les sources pour simplifier la compréhension.

Compilation

Pour compiler le projet, utilisez la commande :

mvn compile

Toutes les dépendances (JUnit, Spring, Lucene, Scala) seront téléchargées automatiquement si vous ne possédez par encore les bonnes versions.

Execution

Pour l’exécuter, vous pouvez utiliser :

mvn exec:java -Dexec.mainClass="fr.chosesafaire.lucene.Main"

Ou le lancer avec un argument (le mot clé recherché, lucene par défaut) :

mvn exec:java -Dexec.mainClass="fr.chosesafaire.lucene.Main" -Dexec.args="computer"

La sortie devrait ressembler à ceci :

Found 2 results.
Lucene in Action
Lucene for Dummies

Vous pouvez modifier le dictionnaire de données en ajoutant des éléments au bean dictionary dans le fichier applicationContext.xml. N’hésitez pas non plus à essayer les différentes classes de Lucene (changer le type de Directory, d’Analyzer…).

L’Analyzer mis en place (StandardAnalyzer) ne tient pas compte de la casse, vous pouvez donc chercher « lucene » ou « Lucene » et obtenir le même résultat.

Le Directory mis en place (RAMDirectory) va comme son nom l’indique stocker temporairement les données dans la mémoire ; bien d’autres types sont disponibles, tout a été résumé dans les commentaires du fichier applicationContext.xml.

Pour rappel, voici les sources du projet.

Aucun article lié

Photo Flickr de BOB008

Or, il existe aujourd’hui, incorporé directement dans Firefox 3.5, les versions les plus récentes de Webkit (Safari 4 notamment) et, cerise sur le gâteau, IE8, un moyen similaire de stocker des informations. Il s’agit de l’objet window.localStorage sur lequel on peut directement travailler pour faire persister des données : ce qu’on y stocke est accessible pour tout le domaine, même après fermeture du navigateur. Il existe également une version basée sur la session courante qui s’appelle assez logiquement window.sessionStorage.

Décidé à expérimenter le système par moi-même, j’ai donc décidé de créer une todo-list très simple sous forme d’un plugin pour jQuery. L’intérêt pratique est bien sûr relativement limité car les données ne sont pas sauvegardées sur un serveur et ne sont donc accessibles et persistantes que depuis un seul navigateur sur un unique poste.

Cela m’a cependant permis de me familiariser avec la création de plugin pour jQuery et la réalisation de la todo-list elle-même était amusante. Pour les opérations de manipulation de chaînes JSON, j’ai choisi de me reposer sur la librairie jquery-json plutôt que de réinventer la lune à ce niveau.

Pour les plus impatients, voilà le lien pour voir la démo … Attention à bien utiliser un navigateur compatible !

Commençons par le plus évident, la page HTML qui va nous servir de base :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Une todo-list avec localStorage</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
    <script type="text/javascript" src="http://jquery-json.googlecode.com/files/jquery.json-2.2.min.js"></script>
    <script type="text/javascript" src="js/todolist.class.js"></script>
    <script type="text/javascript" src="js/todolist.jquery.js"></script>

    <link rel="Stylesheet" href="css/styles.css" />
    
    <script type="text/javascript">
      $(document).ready(function() {
        $('#conteneur-todolist').todoList();
      });
    </script>
  </head>
  <body>
    <h1>Une todo-list avec localStorage</h1>
    <div id="conteneur-todolist"></div>
  </body>
</html>

J’ai ensuite choisi de créer deux fichiers distincts qui vont me permettre de bien séparer la couche métier de mon implémentation.
Voilà tout d’abord la couche métier, la classe TodoList elle-même :

/**
  La classe Todolist va nous permettre de manipuler les tâches et des les 
  faire persister dans la mémoire du navigateur via window.localStorage.
  @param string identifiant 
    L'identifiant unique de la todoList
  @param function cb_mise_a_jour 
    Fonction de callback qui sera appelée à chaque mise à jour de la todoList.
*/
var TodoList = function(identifiant, cb_mise_a_jour) { 

  // Cet identifiant sera sa clé dans le tableau du localStorage
  this.identifiant = identifiant;

  // On récupère les données qui existaient déjà, 
  // ou on utilise les données par défaut.
  this.donnees = $.evalJSON(window.localStorage.getItem(this.identifiant)) || {
    taches : [ 
      {
        'libelle': "Libellé de la première tâche",
        'effectue': false
      },
      {
        'libelle': "Libellé de la deuxième tâche",
        'effectue': false
      },
      {
        'libelle': "Libellé de la troisième tâche ... Elle est finie",
        'effectue': true
      }
    ]
  };

  // L'utilisateur devrait implémenter la méthode de callback pour 
  // rafraîchir son interface à chaque modification de la todolist.
  this.cb_mise_a_jour = cb_mise_a_jour || function() {
    throw 'Vous devriez implémenter la méthode cb_mise_a_jour(instance)';
  }
  
  // On exécute une première fois la méthode pour initialiser l'interface.
  this.cb_mise_a_jour(this);
}


/**
  Retourner toutes les tâches
*/
TodoList.prototype.lister_taches = function() {
  return this.donnees.taches;
}


/**
  Ajouter une nouvelle tâche
  @param string libelle_tache Libellé de la tâche a ajouter. 
*/
TodoList.prototype.ajout_tache = function(libelle_tache) {
  this.donnees.taches.push({
    'libelle': libelle_tache,
    'effectue': false
  });
  this.sauvegarder();
}


/**
  Modifier une tâche
  @param int numero Numéro de la tâche à modifier.
  @param object infos_nouvelle_tache La tâche après mise à jour
*/
TodoList.prototype.modification_tache = function(numero, infos_nouvelle_tache) {
  jQuery.extend(this.donnees.taches[numero], infos_nouvelle_tache);
  this.sauvegarder();
}


/**
  Supprimer une tâche
  @param int numero Numéro de la tâche à supprimer.
*/
TodoList.prototype.suppression_tache = function(numero) {
  this.donnees.taches.splice(numero, 1);
  this.sauvegarder();
}


/**
  Faire persister la TodoList dans le localStorage
*/
TodoList.prototype.sauvegarder = function() {
  window.localStorage.setItem(this.identifiant, $.toJSON(this.donnees));
  this.cb_mise_a_jour(this);
}

Voilà maintenant le plugin jQuery à proprement parler :

/**
  TodoList - Plugin pour jQuery
  Utilisation : $(selecteur_div).todoList();
*/
(function($){
  $.fn.todoList = function(options) {
    
    // On peut utiliser plusieurs TodoLists sur la page
    return this.each(function() {

      // Définition des éléments de l'interface
      var liste_taches = $('<ul></ul>');
      var champ_texte = $('<input type="text" />');
      var bouton_ajout = $('<input type="button" value="Ajouter" />');
      $(this).append(liste_taches, champ_texte, bouton_ajout);
      $(this).attr('class','todolist');
      
      // Action permettant d'ajouter une nouvelle tâche à accomplir
      var ajout_tache = function() {
        var contenu_texte = $(champ_texte).val();
        if(contenu_texte != '') {
          // On crée une nouvelle entrée dans le tableau des tâches.
          TDL.ajout_tache(contenu_texte);
        }
      }
      
      // Ajout de l'écouteur du bouton.
      $(bouton_ajout).click(ajout_tache);
      // Ajout de l'écouteur du champ textuel
      $(champ_texte).keyup(function(e) {
        if(e.keyCode == 13) ajout_tache();
      });
      
      
      // Implémentation de la méthode de callback de la TodoList
      var cb_mise_a_jour = function(TDL) {
        // On vide la liste des tâches et le champ texte
        $(liste_taches).html('');
        $(champ_texte).val('');
        
        // Pour chaque tâche ...
        $.each(TDL.lister_taches(), function(i,tache) {
        
          // On génère un identifiant pour chaque tâche
          tache.identifiant = TDL.identifiant + '_tache_' + i;
          
          // On ajoute la tâche à la liste        
          $(liste_taches).append(
            $('<li></li>')
              .attr('class',(tache.effectue)?'tache_effectuee':'')
              .append(
                $('<input type="checkbox" />')
                  .attr('id', tache.identifiant)
                  .attr('checked', tache.effectue)
                  .click(function() {
                    // Un clic sur la checkbox permet de changer le statut
                    // de la tâche visée.
                    TDL.modification_tache(i, {
                      'effectue': $(this).attr('checked')
                    });
                  })
                ,
                
                $('<label></label>')
                  .attr('for', tache.identifiant)
                  .html(tache.libelle)
                ,
                
                ' '
                ,
                
                // On ajoute la possibilité de supprimer la tâche
                $('<a></a>')
                  .attr('href', 'javascript:void(0)')
                  .attr('title', 'Cliquez pour supprimer la tâche')
                  .click(function() {
                    $(this).parent().fadeOut(function() {
                      TDL.suppression_tache(i);
                    });
                  })
                  .html('x')
              )
          );
        });
      };
      
      
      
      // Instanciation de l'objet TodoList
      try {
        var TDL = new TodoList('todolist_'+$(this).attr('id'), cb_mise_a_jour);
      } 
      catch(e) {
        // En cas d'erreur on avertit l'utilisateur.
        alert("Une erreur s'est produite, il est probable que votre navigateur"+
          " ne supporte pas encore la propriété window.localStorage \n\n" +
          "Message retourné : \n" + e);
      }
      
      
    });
  };
})(jQuery);

Et voilà, quelques styles CSS et on est au bout. En conclusion, je dirais que ce système est assez intéressant surtout pour servir éventuellement de fourre-tout, si votre application a une masse importante de données relativement statiques à transmettre au client. On pourrait imaginer dériver de cette TodoList pour créer un plugin généraliste pour jQuery qui permettait d’utiliser le localStorage s’il est disponible – et sinon se rabattre sur une simple variable globale … J’y réfléchis en ce moment, cela fera sans doute l’objet d’un post ultérieur .

Articles liés :

1. cachedLoad(), un plugin de cache pour jQuery
2. Mocks & Stubs : La suite

Si vos besoins en administration de bases de données ne demandent pas une interface très poussée, pourquoi ne pas jeter un œil du côté d’Adminer ? Ce petit logiciel se présente comme une alternative au classique PhpMyAdmin : plus simple, plus sobre et plus facile à installer, il consiste en un seul et unique fichier PHP à déposer sur votre serveur dédié. Si l’apparence d’origine ne vous convient pas, vous avez même la possibilité d’utiliser une des feuilles de styles proposées sur le site pour le personnaliser à votre guise.

Son interface est mieux conçue à mon sens que celle de PhpMyAdmin, plus simple et plus ergonomique ; ses fonctionnalités s’approchent de son grand frère sur de nombreux points, le dépassent même parfois :

• Un assistant de construction de requête SELECT intéressant dans son fonctionnement et mieux conçu que celui de PhpMyAdmin ; il permet de gagner un temps précieux en vous permettant de rester très proche de la construction d’une requête SQL classique.
• Fonctionnalités basiques d’exportation : elle est disponible uniquement au format SQL et CSV, ce qui devrait suffire dans la majeure partie des cas, mais PhpMyAdmin reste plus complet sur ce point.
• Possibilité d’afficher le schéma de la base sélectionnée sous la forme de multiples divs colorés avec les noms des champs. J’ignore si cette fonctionnalité existe également sous PhpMyAdmin, mais je trouve que c’est un plus sympathique pour ce petit outil.
• Insertion de données dans une table depuis un fichier CSV de votre choix, ça peut toujours servir.
• Plus classiquement, il est au même niveau que PhpMyAdmin pour :
  • Exécution d’une requête arbitraire directement depuis un champ de texte ou un fichier sur votre disque dur.
  • Analyse, Optimisation, Purge de TABLE.
  • Création facile de TABLES, d’INDEX et de TRIGGER.

On a donc affaire à un outil qui se fixe un projet clair, ambitieux et qui remplit parfaitement le rôle qu’il s’est fixé, une belle réussite à mon sens – il a remplacé chez moi PhpMyAdmin, car je ne me servais de toutes façons pas des fonctionnalités qui rendent ce dernier véritablement intéressant. Il nécessite par contre une bonne compréhension du langage SQL, ce qui le rend du coup un peu moins accessible que ne l’est PhpMyAdmin.

Construire un SELECT

L'interface d'Adminer

Générez un schéma de votre base !

Articles liés :

1. Tiny Tiny RSS : une alternative à Google Reader