Netapsys Blog

Spipmedia.net, un référentiel complet de tutoriels pour SPIP

Michael Courcy — Fri, 13 Jun 2008 09:32:00 +0200

Internews est une organisation internationale dont la mission est de soutenir le développement des médias indépendants et l’accès à une information de qualité dans le monde. L’action d’Internews Europe repose sur la conviction qu’un large accès à de l’information riche et fiable est l’un des fondements d’une société ouverte et libre.

Aujourd'hui Internews propose aux journalistes, bloggers, ou simples citoyens partenaires sur ses projets de profiter à plein des nouvelles opportunités de création et de diffusion d'information qu'offre l'Internet.

SPIP a été choisi comme plateforme de publication car il offre aux journalistes un environnement reproduisant les bonnes pratiques d'une rédaction traditionnelle (hiérarchie de la responsabilité éditoriale, suivi des révisions, trace des communications pendant le processus d'édition, système d'archivage par mots clés...) tout en ouvrant l'accès à toutes les possibilités du Web (flux RSS, contenus multimedias, statistiques, moteur de recherche...).

SPIP répond de plus aux besoins de groupes producteurs d'information dont l'équipe éditoriale est éclatée géographiquement (forums privés, messagerie interne, calendrier...). Enfin, la facilité d'emploi de SPIP ainsi que son multilinguisme (SPIP existe en plus de 50 langues, et permet la gestion de plusieurs langues au sein d'un même site) ont été deux critères déterminants.

Mais pour beaucoup de journalistes ou d'activistes, déplacer leur action sur le web n'est pas forcément chose évidente. Avec l'expérience des formations et du support apporté à ces derniers, la nécessité de créer un référentiel de tutoriels cohérents s’est imposée.

C'est ainsi que http://www.spipmedia.net est né.

Aujourd'hui, ce site regroupe plus de 40 leçons réparties sur 4 niveaux, du simple contributeur au niveau webmaster, en plusieurs langues (anglais, persan, birman, khmer...). Tous ces tutoriels ont été écrits avec un très grand souci de cohérence et de qualité. Chaque leçon présente plusieurs démonstrations ou exercices au format Flash ; des screenshots accompagnent systématiquement les explications. L'ensemble a été révisé par au minimum trois relecteurs dont la connaissance de Spip était limitée, afin de garantir l'accessibilité des explications.

De plus, cette documentation en ligne est en constant enrichissement.

Internews a fait appel à la société Netapsys pour la rédaction des leçons exigeant une connaissance poussée de SPIP et pour garantir le respect des bonnes pratiques SPIP.

Aujourd'hui, Spimedia est l'outil privilégié d'Internews pour apporter un support aux journalistes, aux "journalistes webmestres" , ou plus largement aux communautés de rédacteurs que l'organisation soutient à travers ses projets. Une question, un doute, un oubli ... Il y a toujours une démo Flash ou une explication pour y répondre.

Nous sommes heureux de partager avec vous ce site et attendons avec enthousiasme vos retours et propositions d'amélioration.

Polymorphisme des listes génériques

Michael Courcy — Tue, 27 May 2008 13:19:00 +0200

Avec Java 5 les développeurs ont vu pour leur plus grand bonheur arriver dans le langage les types génériques. On allait enfin pouvoir manipuler les List, Set et Map avec un typage fort.

Par exemple avec Java 4, lorsque l'on créait une list, on pouvait y mettre n'importe quel objet :

List menagerie = new ArrayList();
menagerie.put(new Animal());
menagerie.put(new Cat());
menagerie.put(new Dog());
//arg faut pas que je fasse ça
//mais le compilateur ne dit rien 
menagerie.put(new HumanBeing());

Bien sur les risques d'erreurs étaient très élevés car le développeur était le seul garant qu'on ne mettait pas n'importe quoi dans la liste. Sans parler du code de cast que l'on devait écrire pour récupérer les type adhoc :

Iterator it = menagerie.iterator();
//cast obligatoire même si je sais que ma 
//list ne contient que des animaux
Animal animal = (Animal) it.next();

Mais en Java 5 tous ces problèmes sont "résolus" avec les types génériques (je dis résolu entre guillemet vous allez bientôt voir pourquoi).

List menagerie<Animal> = new ArrayList<Animal>();
menagerie.put(new Animal());
menagerie.put(new Cat());
menagerie.put(new Dog());
 
//compile pas ....
menagerie.put(new HumanBeing());

Enfin plus de cast necessaires lorsqu' on parcourt la liste :

Iterator<Animal> it = menagerie.iterator();
//pas obligé de caster
Animal animal =  it.next();

Mais quid du polymorphisme des types génériques ?

C'est ici que les développeurs ne comprennent plus, et c'est compréhensible.

Supposons que je développe une methode

public void nourrit(List<Animal> menagerie);

J'aimerais pouvoir l'invoquer en lui passant une liste de chats par exemple

List<Cat> cats = new ArrayList<Cat>();
//compile pas ....
nourrit(cats);

Ce code ne compile pas, la méthode nourrit attend une liste d'animaux pas une liste de chats, même si le chat est un animal ... Difficile de comprendre pourquoi, le chat hérite de animal, donc tout ce que cette méthode fait avec des animaux elle doit pouvoir le faire avec des chats. Logique et pourtant non le compilateur refuse.

Deux questions viennent alors :

Pourquoi ?
Il y a-t-il une solution à ce problème ?

Répondons à la première : Pourquoi ?

Cette situation est d'autant plus troublante que le polymorphisme avec les tableaux est quant à lui possible :

//j'ai développé cette méthodes
public void nourrit(Animal[] menagerie);
 
//compile sans problème car Cat hérite de Animal
Cat[] cats = new Cat[15];
nourrit(cats);

Seulement vous pouvez aussi faire de grosses bêtises : Supposons que je développe cette méthode qui met un chat en tête du tableau d'animaux qu'on lui passe

public void metUnChatAuDebut(Animal[] animals){
   animals[0] = new Cat();
}

Je peux tout à fait invoquer cette méthode de la façon suivante :

Dog[] dogs = {new Dog(), new Dog(), new Dog()};
//ça compile parfaitement
metUnChatAuDebut(dogs);
//aïe !!! J'ai mis un chat dans un tableau de chiens, pauvre minou !

Si vous exécutez ce code, vous déclencherez une ArrayStoreException. C'est le chat qui souffle : jamais il n'aurait pensé que l'ArrayStoreException lui serait un jour salutaire.

En clair à l'exécution la machine virtuelle sait que le tableau qui lui est passé est un tableau de Dog et qu'on ne peut y mettre que des Dog ou des classes héritant de Dog et si vous avez pu échapper à la vigilance du compilateur vous n'échapperez pas à celle de la machine virtuelle.

Mais pour les listes typées, il en va tout autrement. En effet, pour pouvoir maintenir le code qui a été écrit à l'époque où les listes n'étaient pas génériques, Sun a choisi de ne faire de la généricité qu'une affaire de compilation. En fait au niveau bytecode ce sont toujours des Objects qui sont manipulés, ajoutés, retirés.

Ce qui signifie que par rapport à l'exemple précédent, on pourrait aller un cran plus loin dans l'exécution et effectivement mettre un chat dans une liste de chiens, car pour la JVM on met finalement un Object dans une liste d'Objects et ça pour le chat ça risque d'être un moment très pénible.

C'est parce que cette sécurité supplémentaire n'existe pas que Sun a décidé d'interdire une utilisation aussi directe du polymorphisme :

public void ajouteUnChat(List<Animal> animals){
   animals.add(new Cat());
} 
 
List<Dog> dogs = new ArrayList<Dog>(); 
dogs.add(new Dog()); 
dogs.add(new Dog()); 
dogs.add(new Dog());
//ça ne compilera pas !!!
//et c'est peut être pas plus mal ...
ajouteUnChat(dogs);

Et ceci nous amène à la deuxième question.

Y a-t-il une solution à ce problème ?

Oui, mais à deux conditions :

si vous promettez de ne faire que des opérations de lecture sur la liste alors vous pourrez passer une liste de Dog à une méthode attendant une liste d'Animal
En respectant la syntaxe wildcard

public int compteLesAnimaux(List<? extends Animal> animals){
   //fait une opération qui n'ajoute pas d'élément à la liste 
   //ou ne réassigne pas un élément de la liste 
   //par exemple
   return animals.size() 
} 
 
List<Dog> dogs = new ArrayList<Dog>(); 
dogs.add(new Dog()); 
dogs.add(new Dog()); 
dogs.add(new Dog());
//ça compile !!
compteLesAnimaux(dogs);

Mais ce code ne compilera pas :

public void ajouteUnChat(List<? extends Animal> animals){
   //erreur de compilation 
   animals.add(new Cat());
} 
 
//ce qui suit ne présente pas beaucoup 
//d'intérêt puisque ce qui précède ne 
//compile pas
List<Dog> dogs = new ArrayList<Dog>(); 
dogs.add(new Dog()); 
dogs.add(new Dog()); 
dogs.add(new Dog());
ajouteUnChat(dogs);

Si la généricité avait été proposée dès le départ, Sun aurait certainement eu d'autres options. On peut dire que les choix qui ont été faits sont ceux du moindre mal, mais dès lors ils deviennent un peu difficile à appréhender.

Vous trouverez en pièce jointe un micro projet eclipse illustrant mes propos.

Introduction à Spring MVC

Michael Courcy — Sun, 13 Apr 2008 01:14:00 +0200

Dans la guerre furieuse des frameworks MVC il y en a un qui se démarque par sa simplicité, sa facilité de prise en main et sa parfaite intégration à Spring : Spring MVC.

Certes Spring MVC n'est pas un framework événementiel comme pourraient l'être jsf, wicket, tapestry ou struts 2. Mais il possède de nombreux points d'extensions et utilisé avec Spring Web Flow il devient un framework très puissant.

Je vous propose ici une introduction des plus simples qui va consister à afficher une page Hello Spring MVC avec le framework Spring MVC.

Puis nous enrichirons progressivement notre application exemple avec de nouveaux tutoriels pour aboutir à l'utilisation de Spring Web Flow avec la gestion d'une transaction longue Hibernate.

Le projet est un projet Maven, tout ce qu'il y a de plus simple que vous pouvez télécharger ici.

Sinon je vous propose (et vous conseille) de le construire pas à pas avec moi :

Etape 1 : création du projet

Créons un projet web avec maven :

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=com.netapsys.springmvc  -DartifactId=spring-mvc-webapp

Pour pouvoir utiliser les annotations notre projet doit être un projet en java 1.5. Ouvrez le pom.xml situé dans le répertoire que vous venez de créér spring-mvc-webapp et ajoutez ces informations entre les balises build. Vous devriez obtenir ceci :

<build>
  <finalName>spring-mvc-webapp</finalName>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </plugin>	
    <plugin>
      <artifactId>maven-eclipse-plugin</artifactId>
      <version>2.4</version>
      <configuration>					
        <downloadSources>true</downloadSources>
        <downloadJavadocs>true</downloadJavadocs>					
      </configuration>
    </plugin>		
  </plugins>
</build>

Pour bien faire, j'indique aussi au plugin eclipse que je souhaite disposer des codes sources, ce qui est toujours un très bon choix quand on travail avec du code open-source.

Ensuite il faut en faire un projet eclipse : allez dans le répertoire que vous venez de créér et lancez la commande maven eclipse:eclipse

cd spring-mvc-webapp
mvn eclipse:eclipse

Puis importez le projet dans eclipse en vous étant assuré que la variable M2_REPO pointe bien vers votre répertoire ~/.m2/repository Si ce n'est pas le cas : windows > preference > Java > Build Path > Class path variables puis New pour créer une nouvelle variable.

Par exemple pour moi M2_REPO = C:/Documents and Settings/michael_courcy/.m2/repository

Etape 2 : Exécution de l'application avec le serveur web jetty

Une fois notre projet créé nous allons modifier le pom.xml pour pouvoir exécuter ce projet sous le serveur web jetty :

Vous devriez obtenir ceci :

<build>
  <finalName>spring-mvc-webapp</finalName>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.mortbay.jetty</groupId>
      <artifactId>maven-jetty-plugin</artifactId>
      <version>6.0.1</version>
      <configuration>
        <scanIntervalSeconds>10</scanIntervalSeconds>
      </configuration>
    </plugin>
  </plugins>
</build>

Remarquez qu'ici je n'ai fait que configurer jetty. Maven téléchargera lui-même jetty si nécessaire.

Vérifions que notre configuration fonctionne bien et exécutons l'application.

mvn jetty:run

Si vous n'avez pas l'habitude d'utiliser maven pour vos applications web, Maven téléchargera nécessairement de nombreuses dépendances transitives. C'est peut être l'occasion de prendre un café ...

Enfin, si tout s'est bien passé, vous pouvez vous connecter à l'url : http://localhost:8080/spring-mvc-webapp/

Pour y découvrir l'éternel Hello World.

Etape 3 : Branchement de Spring MVC

Spring mvc fonctionne par certains aspects de façon similaire à Struts : une servlet frontale va prendre l'ensemble des requêtes et les dispatcher à ses contrôleurs, ces contrôleurs sont des singletons issus d'une fabrique Spring.

Donc ce que je vais trouver dans web.xml :

Une servlet pour dispatcher les requêtes aux contrôleurs.
Un mapping de servlet

On aboutit à ce fichier web.xml :

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >
 
<web-app>
  <display-name>Archetype Created Web Application</display-name>
 
  <!-- déclare la servlet frontale (très similaire à struts)  -->
  <servlet>
    <servlet-name>spring-mvc-webapp</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>2</load-on-startup>
  </servlet>
 
  <!-- Toutes les requêtes se terminant par .html seront servis par la servlet frontal -->
  <servlet-mapping>
    <servlet-name>spring-mvc-webapp</servlet-name>
    <url-pattern>*.html</url-pattern>
  </servlet-mapping>
 
</web-app>

Avant de recopier ce fichier, coupez jetty (Ctrl + C dans le terminal).

Ajoutez la dépendances à Spring et à spring-webmvc dans le pom.xml :

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring</artifactId>
  <version>2.5.3</version>
</dependency>
<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-webmvc</artifactId>
   <version>2.5.3</version>
</dependency>

puis régénérez votre projet eclipse :

mvn eclipse:clean eclipse:eclipse

enfin rafraîchissez votre projet eclipse quand l'opération est finie pour voir apparaitre vos librairies et éventuellement consulter le code source.

On remarque immédiatement à la lecture de web.xml qu'on ne voit pas comment on informe la servlet frontale des contrôleurs auxquels elle va devoir redispatcher les requêtes.

Par convention, si la servlet s'appelle spring-mvc-webapp, alors elle ira chercher sa fabrique de contrôleurs dans WEB-INF/spring-mvc-webapp-servlet.xml. C'est une convention qui peut être surdéfinie mais que nous allons suivre ici.

Voici donc le fichier spring-mvc-webapp-servlet.xml. Les commentaires détaillent chaque élément : je vous invite à les lire.

<?xml version="1.0" encoding="UTF-8"?>
<!--
  - Contexte d'application pour spring-mvc-webapp.
-->
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
		xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
 
  <!--
    - Tous les contrôleurs sont automatiquement détectés grâce à l'annotation @Controller.
    - On définit ici dans quel package le post processor doit chercher ces beans éventuellement annotés.
  -->
  <context:component-scan base-package="com.netapsys.springmvc.web"/>
 
    <!--
      - Les controlleurs de cette application fournissent une annotation @RequestMapping 
      - Qui peuvent être déclaré de deux manière différentes : 
      - Au niveau de la classe par exemple : 
      -     @RequestMapping("/addVisit.html")
      -     Pour ce type de controlleurs on peut annoter les méthodes pour qu'elles
      -     prennent en charge une requête Post ou une requête Get
      -     @RequestMapping(method = RequestMethod.GET)
      - Ou alors au niveau de chaque méthode, différents exemples  seront fournis.		 
    -->
 
    <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"/>
      <!--
        Ceci est le view resolver, il permet de définir la technologie de vue utilisée et comment
        sélectionner une vue. Ici on prendra la solution la plus simple, elle permet de mapper 
        le nom de la vue retournée avec la sélection d'une jsp.
        Exemple si le nom de la vue retournée est "foo/bar/hello" alors on utilisera le fichier
        WEB-INF/jsp/foo/bar/hello.jsp pour constuire la vue. 
      -->
      <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver" p:prefix="/WEB-INF/jsp/" p:suffix=".jsp"/>
 
</beans>

Tout est en place maintenant pour écrire notre premier contrôleur et notre première jsp.

Etape 4 : Notre premier contrôleur

Créez le source folder /src/main/java/ et créez la classe HelloSpringMVC dans le package com.netapsys.springmvc.web

package com.netapsys.springmvc.web;
 
import org.springframework.stereotype.Controller;
import org.springframework.ui.ModelMap;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
 
/**
 * Contrôleur que l'on invoquera pour l'url /helloSpringMVC.html.
 * 
 * @author Michael Courcy
 *
 */
@Controller
@RequestMapping("/helloSpringMVC.html")
public class HelloSpringMVC {
 
  /**
    * Handler de la méthode Get pour l'URL /helloSpringMVC.html. 
    * 
    * @param name le nom que l'on doit afficher dans la vue.
    * @param model une map de toutes les données qui seront utilisables dans la vue 
    * @return le nom de la vue qu'il faudra utiliser.
    */
  @RequestMapping(method = RequestMethod.GET)
  public  String sayHelloWithSpringMVC(
    @RequestParam(value="name",required=false) String name, 
    ModelMap model) 
  {
    model.addAttribute("name",name);
    // on utilisera donc le fichier /WEB-INF/jsp/hello.jsp
    //au regard de la stratégie de résolution des vues 
    //utilisée dans cette application.
    return "hello";
  }
}

Plusieurs remarques sont à faire à la lecture de ce contrôleur :

Le contrôleur n'hérite d'aucune classe particulière, il est identifié comme contrôleur grâce à l'annotation @Controller
C'est encore une annotation qui permet de savoir quelle méthode invoquer pour une requê

te de type Get : @RequestMapping(method = RequestMethod.GET)

Notre méthode prend un paramètre supplémentaire ModelMap qui est en fait un HashMap amélioré dans lequel on place toutes les informations que l'on souhaite disponibles lors de la génération de la vue avec la jsp.
Le code n'utilise pas directement l'objet HttpServletRequest mais il indique encore grâce aux annotations comment renseigner les paramètres à partir du contenu de l'objet HttpServletRequest @RequestParam(value="name",required=false)

Ce dernier point est très important : ne pas utiliser directement l'objet HttpServletRequest nous permet de créer des tests unitaires très simplement sans avoir à créer de request mock.

Créez le source folder /src/test/java et créez aussi le package com.netapsys.springmvc.web pour y placer le test suivant

package com.netapsys.springmvc.web;
 
import org.springframework.ui.ModelMap;
 
import junit.framework.TestCase;
 
public class HelloSpringMCVTest extends TestCase {
 
  public void testSayHelloWithSpringMVC(){
    HelloSpringMVC helloSpringMVC = new HelloSpringMVC();
    ModelMap model = new ModelMap();
    String view = helloSpringMVC.sayHelloWithSpringMVC("mic", model);
    //vérifions que c'est bien la vue hello qui est générée
    assertEquals("hello", view);
    //vérifions que le modele contient bien un attribut name
    assertTrue(model.containsAttribute("name"));
    //vérifions que cet attribut name est bien "mic"
    assertEquals("mic",model.get("name"));
  }
}

Vous pouvez lancer ce test avec maven :

mvn -Dtest=HelloSpringMCVTest test

pour un test particulier ou alors

mvn test

pour refaire tous les tests.

Etape 5 : Notre propre jsp

Créez le fichier WEB-INF/jsp/hello.jsp :

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<%@ page isELIgnored ="false" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Spring mvc hello !!</title>
</head>
<body>
 
Hello spring mvc vous donne votre nom qui est : ${name}
 
</body>
</html>

Il ne vous reste plus qu'à tester

mvn jetty:run

Puis à essayer l'url suivante : http://localhost:8080/spring-mvc-webapp/helloSpringMVC.html?name=mic

Hibernate - Utilisation efficace de l'API Criteria

Michael Courcy — Wed, 02 Apr 2008 17:06:00 +0200

Utiliser l'API criteria plutôt que le langage de requête HQL présente de sérieux avantages. Parmi l'un deux, on peut en considérer un particulièrement interessant : la décoration de requête.

Supposons que vous ayez écrit une classe de DAO assez générique avec une méthode de requête paginée.

class GenericDaoHibernate<T, PK extends Serializable>
    implements GenericDao<T, PK> {
 
    /**
      * La classe persistante sur laquelle nous allons faire nos requêtes
      */
    private Class<T> persistentClass;
 
    /**
     * Constructeur initialisant la classe persistante à manipuler
     * Ceci nous permettra de développer des classes de DAO fortement typée.
     * 
     * @param persistentClass the class type you'd like to persist
     */
    public GenericDaoHibernate(final Class<T> persistentClass)
    {
        this.persistentClass = persistentClass;
    }
 
    public List<T> getAll(final SearchCriteria searchCriteria)
    {
        //récupérons la session et créons un critère
        final Session session = getSessionFactory().getCurrentSession();
        final Criteria crit = session.createCriteria(persistentClass);
 
        // gestion de l'ordre des résultats
        if (searchCriteria.isDesc()) {
            crit.addOrder(Order.desc(searchCriteria.getActiveOrder()));
        }
        else {
            crit.addOrder(Order.asc(searchCriteria.getActiveOrder()));
        }
 
        // Les sous classes de GenericDaoHibernate
        // devront redéfinir cette méthode pour ajouter des 
        // critères supplémentaires
        addExtraCriteria(crit, searchCriteria);
 
        // Procédons à un comptage du résultat total de la requête
        // mais sans charger la collection d'objets.
        // D'une certaine manière on peut dire que le 
        // critère bascule en mode "comptage".
        crit.setProjection(Projections.countDistinct("id"));
        final Long totalResult = new Long((Integer) crit.uniqueResult());
        searchCriteria.setTotalResult(totalResult);
 
        // On rebascule en mode "liste d'objets"
        // si l'on est amené a faire des jointures assurons nous que la liste 
        //qui nous est retournée est réellement unique       
        crit.setProjection(null);
        crit.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
 
        // puis retournons la liste dans les limites de la pagination
        return crit
                .setMaxResults(searchCriteria.getNumberOfResultPerPage())
                .setFirstResult( (int) (searchCriteria.getActivePage() - 1)  * searchCriteria.getNumberOfResultPerPage())
                .list();
    }
 
    /**
     * Les sous classes doivent surdéfinir cette méthode pour ajouter plus de contraintes à la recherche.
     * 
     * @param crit  le critere  hibernate que l'on veut modifier.
     * @param searchCriteria Le critère de recherche fourni par la couche service.
     */
    public void addExtraCriteria(final Criteria crit,
            final SearchCriteria searchCriteria)
    {
        // rien : c'est la sous classe qui redéfinira le corps de la méthode
    }
 
}

Si vous lisez attentivement ce code, vous constatez qu'il couvre des besoins très génériques :

Récupération d'une collection d'objets
Pagination des résultats
Gestion systématique d'un ordonnancement

Et bien entendu, on souhaiterait ne pas récrire ça à chaque requête ... Par exemple ProductHibernateDao devrait pouvoir utiliser ce travail en restreignant le résultat à une catégorie ou à la comparaison d'une chaîne dans le libellé des contenus localisés du produit.

Heureusement, pour ce faire, ProductHibernateDao n'a qu' à redéfinir la méthode addExtraCriteria(final Criteria crit, final SearchCriteria searchCriteria).

Voici un exemple d'implémentation de ProductHibernateDao :

public class ProductDaoHibernate
    extends GenericDaoHibernate<Product, Long>
    implements ProductDao
{
 
   public ProductDaoHibernate()
    {
        super(Product.class);
    }    
 
 
    /**
     * {@inheritDoc}
     * 
     * @see com.netapsys.shop.dao.hibernate.GenericDaoHibernate#addExtraCriteria(org.hibernate.Criteria,
     * com.netapsys.shop.flow.SearchCriteria)
     */
    @Override
    public void addExtraCriteria(final Criteria crit,
            final SearchCriteria searchCriteria)
    {
        ProductCriteria productCriteria = (ProductCriteria) searchCriteria;
        // On restreint la recherche a une catégorie si elle est définie.
        if (productCriteria.getCategory() != null
                && productCriteria.getCategory().getId() != null) {
            crit.add(Expression.eq("category.id", productCriteria.getCategory()
                    .getId()));
        }
 
        if (productCriteria.getSearchOn() != null
                && !productCriteria.getSearchOn().equals("none")) {
            // On recherche une chaîne de caractères "sword" dans la référence produit
            if (productCriteria.getSearchOn().equals("ref")) {
                crit.add(Expression.ilike("ref", productCriteria.getSword(),
                        MatchMode.ANYWHERE));
            }
            // Remarquez qu'ici j'utilise une fonction puissante de 
            // l'API Criteria qui me permet de rechercher 
            // dans une sous collection de Product.
            if (productCriteria.getSearchOn().equals("title")) {
                crit.createCriteria("localizedProductContents").add(
                        Expression.ilike("publishInfo.title", productCriteria
                                .getSword(), MatchMode.ANYWHERE));
            }
        }
    }
 
}

Ainsi, tout le processus de requêtage et de pagination a pu être mutualisé dans GenericHibernateDao alors que le requêtage particulier a été déplacé dans les classes dérivées, ici par exemple ProductHibernateDao.

On a d'une certaine manière décoré la requête en modifiant l'objet Criteria par la classe fille. Il ne s'agit pas néanmoins de la véritable mise en oeuvre d'un pattern décorateur mais la chose pourrait tout à fait être envisagée avec l'utilisation des critères détachés.