La version 2 de Pleade n'est plus officiellement développée par Anaphore et AJLSM. Si des bogues bloquants sont constatés, ils pourront toutefois être corrigés.

Nous encourageons tous les utilisateurs de Pleade 2 à songer à une migration vers la version 3.

La version 3.1 est disponible depuis le 24 février 2009 sur SourceForge : > > Télécharger...

Voir le site de démonstration de Pleade 3 : > > Démonstration de Pleade 3

Plus d'information sur Pleade 3 : http://pleade.com/

Formulaires de recherche avancée

1) Approche générale

Dans une application SDX telle que PLEADE, il est possible d'offrir aux utilisateurs des formulaires de recherche relativement complexes et souples. Toutefois, pour chaque formulaire, il faut non seulement préciser comment il sera affiché, mais également comment il sera traité par SDX pour réellement effectuer la recherche souhaitée depuis les informations saisies ou choisies par l'utilisateur.

Pour simplifier le travail des administrateurs de sites PLEADE, nous avons implanté un mécanisme de création de formulaires de recherche et de programmes de traitement basé sur une simple description de la structure du formulaire, description qui sert à la fois à générer un affichage et un programme de traitement. Ainsi, il suffit de fournir des informations comme le titre du formulaire, une introduction, un nom court, et enfin la liste des champs à chercher et la manière de les chercher. PLEADE fera ensuite le nécessaire pour que tout fonctionne correctement.

Les formulaires de recherche sont décrits à l'aide d'un document XML qui doit se situer dans le dossier pleade-local/search-forms. La structure de ces documents XML est précisée dans les sections suivantes de ce document.

2) Interface de paramétrage

Avertissement

Cette interface de paramétrage est disponible depuis la version 2.0 de PLEADE uniquement.

Une interface de paramétrage peut être utilisée pour créer et modifier des formulaires de recherche avancée. Elle peut également être utilisée pour récupérer la définition de formulaires existants, ou encore charger de telles définitions sur le serveur.

Cette interface est décrite dans un document à part.

3) Structure de la description

3.1) Informations générales

La première partie de la structure du formulaire consiste à fournir des informations générales qui seront utilisées pour introduire le formulaire ou encore offrir des liens vers ce formulaire. Voici d'abord un exemple de description de formulaire de recherche, en insistant sur cette première partie :

  <form action="search-a.xsp" general="true" name="standard" documents="ead">
    <title xml:lang="fr">Formulaire de recherche avancée</title>
    <title xml:lang="en">Advanced search form</title>
    <short-title xml:lang="fr">Général</short-title>
    <short-title xml:lang="en">General</short-title>
    <introduction xml:lang="fr">
      <p>Vous pouvez utiliser ce formulaire de recherche pour trouver
          des documents dans l'ensemble de la base.
      </p>
    </introduction>
    <introduction xml:lang="en">
      <p>You may use this search form to query all the database.</p>
    </introduction>

    <!-- Ici devraient suivre les champs de recherche... -->
  </form>

Il y a donc six éléments d'information à fournir dans ces généralités, à l'aide de trois attributs de l'élément form et de trois sous-éléments de ce dernier.

Attribut action

Cet attribut permet de préciser l'URL du programme de traitement du formulaire de recherche avancée. Pour l'instant, la valeur de cet attribut doit toujours être search-a.xsp.

Attribut general

Cet attribut peut prendre les valeurs true ou false, et permet de préciser si ce formulaire sera offert parmi la liste des formulaires de recherche avancée ou non. En effet, dans l'interface par défaut de PLEADE, on retrouve en haut de page un formulaire de recherche simple mais également un lien vers un ou plusieurs formulaires de recherche avancée. Les formulaires de recherche avancée qui sont présentés dans cette liste sont ceux dont l'attribut general a la valeur true.

Attribut name

Cet attribut permet de donner un identifiant au formulaire, identifiant qui sera utilisé par PLEADE pour en assurer la gestion, autant à l'affichage qu'au traitement. Les attributs name des formulaires doivent tous avoir une valeur différente dans une installation PLEADE.

Attribut documents

Cet attribut sert, dans une installation construite à partir des sources de PLEADE 2 uniquement, à spécifier quel corpus de documents on souhaite interroger ; les valeurs possibles sont donc ead et eac.

Sous-élément title

Cet élément contient le titre du formulaire de recherche avancée. Ce titre sera présenté en début de page lorsque le formulaire est affiché. Ce titre doit avoir un attribut xml:lang pour chaque langue d'interface que vous offrez à vos utilisateurs. Il peut y avoir autant de langues que vous souhaitez.

Sous-élément short-title

Cet élément contient le titre court du formulaire de recherche avancée. Ce titre court sera utilisé lorsqu'on offre un lien vers le formulaire de recherche à partir d'un menu déroulant, par exemple dans l'en-tête des pages s'il s'agit d'un formulaire général. Ce titre court doit avoir un attribut xml:lang pour chaque langue d'interface que vous offrez à vos utilisateurs. Il peut y avoir autant de langues que vous souhaitez.

Sous-élément introduction

Cet élément contient un texte d'introduction au formulaire. Ce texte d'introduction est optionnel, mais s'il est présent il sera présenté sous le titre lorsqu'on affiche le formulaire. Le contenu de cet élément doit être du texte balisé en XHTML, ce qui vous permet d'enrichir le texte ou de le structurer visuellement. Cette introduction doit avoir un attribut xml:lang pour chaque langue d'interface que vous offrez à vos utilisateurs. Il peut y avoir autant de langues que vous souhaitez.

3.2) Critères de recherche

Après les informations générales, ce sont les critères de recherche qui doivent être spécifiés. Le mécanisme des formulaires de recherche avancée dans PLEADE supporte une liste plate de critères de recherche, chaque critère étant relié au précédent par un opérateur booléen. L'exemple ci-dessous présente une description générique de critères de recherche, permettant de voir toute l'étendue des possibilités :

  <form ...>
    <!-- Les informations générales ne sont pas reprises dans cet exemple -->

    <!-- Un critère caché -->
    <key type="hidden" field="[champ]" value="[valeur]" connector="[opérateur]"/>

    <!-- Une zone de texte avec choix ou pas du champ de recherche -->
    <key type="text" connector="[opérateur]" style="[instructions CSS]">

      <!-- Le libellé pour le critère -->
      <label xml:lang="fr">Intitulé en français</label>
      <label xml:lang="en">English label</label>

      <!-- Le ou les champs de recherche -->
      <field name="[champ1]">
        <label xml:lang="fr">Intitulé en français</label>
        <label xml:lang="en">English label</label>
      </field>
      <field name="[champ2]">
        <label xml:lang="fr">Intitulé en français</label>
        <label xml:lang="en">English label</label>
      </field>
      ...
    </key>

    <!-- Autres critères possibles définis ci-après -->

  </form>

L'exemple ci-dessus permet de voir, de manière générale, comment sont définis les critères de recherche. Chaque critère est défini avec des informations qui sont soit communes à tous les types de critères, soit spécifique à un type de critère.

Les informations communes sont  :

  • L'élément key représente toujours un critère de recherche.

  • L'attribut type de l'élément key permet de préciser le type de critères dont il s'agit, ce qui aura une influence sur l'apparence de ce critère et la manière de l'utiliser. Les valeurs possibles sont text, list, hidden, date et boolean. Des précisions sur chaque type de critères sont apportées ci-dessous.

  • L'attribut connector de l'élément key permet d'indiquer quels opérateurs booléens affecter à ce critère pour le relier au précédent. Les valeurs possibles sont 1 (ET), 2 (OU), 3 (ET/OU), 4 (SAUF).

  • L'attribut style de l'élément key permet de fournir des spécifications CSS qui seront copiées dans l'élément HTML correspondant au critère. Cela est utile pour indquer la largeur souhaitée d'une zone de texte par exemple.

  • Le sous-élément label, qualifié par un code de langue, permet de spécifier l'étiquette à associer au champ, et ce dans les différentes langues d'interface.

4) Présentation des différents critères de recherche

Chaque type de critère de recherche partage des éléments communs spécifiés dans la section précédente. Ici, nous allons les reprendre un par un et indiquer les spécifications complémentaires propres à chaque type, ainsi qu'un exemple complet d'un critère de ce type.

4.1) text = zone de texte

Ce type de critère permet d'afficher une zone de texte dans laquelle l'utilisateur pourra saisir des mots ou expressions à rechercher. Cela s'apparente à la recherche site simple. La recherche peut s'effectuer dans un champ prédéfini, ou encore elle peut s'effectuer dans un champ spécifié par l'utilisateur à partir d'une liste.

Voici un exemple complet lorsqu'il y a un champ de recherche prédéfini :


<!-- Une zone de texte champ de recherche prédéfini -->
<key type="text" connector="3" style="width: 40em;" field="fulltext">

  <!-- Le libellé pour le critère -->
  <label xml:lang="fr">Recherche plein texte :</label>
  <label xml:lang="en">Full text search</label>

</key>

Dans cet exemple, cette nouvelle spécification est introduite  :

  • L'attribut field de l'élément key indique le champ de recherche prédéfini.

Un second exemple permet de comprendre comment se construit un critère de recherche où l'utilisateur peut indiquer dans quel champ il veut effectuer sa recherche, depuis une liste déroulante :


<!-- Une zone de texte avec choix du champ de recherche -->
<key type="text" connector="3" style="width: 40em;">

  <!-- Les champs de recherche -->
  <field name="fulltext">
    <label xml:lang="fr">Texte intégral</label>
    <label xml:lang="en">Full text</label>
  </field>
  <field name="scopecontent" default="true">
    <label xml:lang="fr">Description du contenu</label>
    <label xml:lang="en">Scope content</label>
  </field>
  <field name="unittitle">
    <label xml:lang="fr">Intitulés seulement</label>
    <label xml:lang="en">Unit titles only</label>
  </field>
  ...
</key>


Dans cet exemple, ces nouvelles spécifications sont introduites  :

  • Le sous-élément field indique un champ de recherche qui fera partie de la liste présentée à l'utilisateur.

  • L'attribut name de l'élément field indique le champ de recherche.

  • L'attribut default de l'élément field, lorsqu'il a pour valeur true, permet d'indiquer le champ sur lequel sera positionné le menu déroulant.

  • Le sous-élément label de l'élément field indique le l'étiquette du champ dans la liste présentée à l'utilisateur.

Ce type de critère peut être utilisé à la fois pour une recherche dans un champ de type mot (type word dans la terminologie SDX) ou pour une recherche dans un champ de type champ (type field dans la terminologie SDX). PLEADE saura reconnaître la nature du champ et fabriquera la bonne requête.

4.2) list = liste déroulante

Ce type de critère permet de montrer à l'utilisateur une liste déroulante contenant toutes les valeurs d'un champ, ou une partie des valeurs d'un champ selon certains critères de filtre. Différentes variantes de listes sont possibles, et l'exemple suivant présente toutes les valeurs possibles de tous les paramètres, même si toutes les combinaisons ne sont pas utiles.


<key
     type="list"
     connector="3"
     field="fpersname"
     variant="combo|fixed|radio|checkbox"
     display="vertical|horizontal"
     placement="right|left"
     rows="10"
     selection="single|multiple|double-list"
>
  <label xml:lang="fr">Nom de personne</label>
  <label xml:lang="en">Personal name</label>
  <no-choice xml:lang="fr">-- Sélectionner un nom --</no-choice>
  <no-choice xml:lang="en">-- Please select a name --</no-choice>
  <items>
    <item value="Bonaparte, Napoléon">
      <label xml:lang="fr">Napoléon Bonaparte</label>
      <label xml:lang="en">Bonaparte</label>
    </item>
    <item value="De Gaulle, Charles">
      <label xml:lang="fr">Charles de Gaulle</label>
      <label xml:lang="en">CDG</label>
    </item>
  </items>
</key>

Ces nouvelles spécifications sont introduites dans l'exemple :

  • L'attribut field permet de préciser le champ de recherche.

  • L'attribut variant permet de spécifier la variante de liste, et les valeurs possibles sont  :

    • combo : une liste de type combo box, soit une liste déroulante dont seule l'entrée sélectionnée est visible.

    • fixed : une liste avec un nombre fixe d'entrées qui apparaisent à l'écran.

    • radio : une liste où chaque entrée peut être sélectionnée à l'aide d'un bouton de radion, ce qui permet la sélection d'une seule valeur.

    • checkbox : une liste où chaque entrée peut être sélectionnée à l'aide d'une case à cocher, ce qui permet la sélection de plusieurs valeurs.

  • L'attribut display permet d'indiquer plus précisément le type d'affichage ; il est pertinent seulement pour les variantes checkbox et radio, et il peut prendre les valeurs horizontal pour obtenir des valeurs qui s'affichent les unes à côté des autres (pour les petites listes...) ou vertical pour obtenir des valeurs qui s'affichent les unes au-dessus des autres. Cet élément est optionnel et sa valeur par défaut est vertical.

  • L'attribut placement permet de déterminer si on veut placer les cases à cocher ou les boutons de radion à gauche de la valeur (left) ou à droite de la valeur (right). Ce paramètre est pertinent seulement pour ces deux types de liste, et la valeur par défaut est left.

  • L'attribut rows permet d'indiquer le nombre de lignes visibles dans la liste. Il est optionnel et sa valeur par défaut est déterminée par le navigateur Web. Ce paramètre est pertinent seulement pour les listes de type combo ou fixed.

  • L'attribut selection permet d'indiquer si on peut sélectionner une seule valeur (single) ou plusieurs valeurs multiple). Cet attribut est optionnel et la valeur par défaut est single. Veuillez noter également que la valeur multiple n'est pas possible avec une liste de type combo et elle sera donc ignorée dans ce cas. On peut également utiliser la valeur double-list pour indiquer que les sélections multiples sont possibles et que les valeurs sélectionnées seront présentées dans une seconde liste, présentée à droite de la liste complète des valeurs. Cette méthode est pratique pour permettre aux utilisateurs de voir toutes les valeurs sélectionnées sans avoir à dérouler la liste principale de l'ensemble des valeurs.

  • Le sous-élément label permet d'indiquer le libellé qui présente le champ, dans toutes les langues souhaitées. A noter que ce sous-élément est optionnel, et s'il n'est pas présent, aucun espace ne sera alloué au libellé. Ceci est pratique lorsque, par exemple, la ligne visible d'une liste (voir ci-après) indique déjà clairement ce que contient la liste.

  • Le sous-élément no-choice permet d'indiquer le texte qui sera utilisé comme première entrée de la liste, pour indiquer aucune sélection ou pour inviter l'utilisateur à sélectionner une valeur.

  • Le sous-élément items permet d'indiquer les items à insérer dans la liste. Le sous-élément items permet donc de définir une liste avec des valeurs prédéterminées, par exemple lorsqu'on veut seulement proposer certaines options de recherche et pas nécessairement toutes celles qui sont dans un champ, où lorsqu'on veut diriger l'utilisateur dans l'expression de ses requêtes. L'exemple ci-dessus fournit toutes les informations nécessaires pour comprendre l'utilisation de ces listes prédéfinies : chaque item à présenter dans la liste est dans un élément item, dont l'attribut value indique la valeur à chercher si cet item est sélectionné par l'utilisateur. Ensuite, dans un élément item, on indique le libellé de l'item (ce qui sera affiché à l'écran), dans toutes les langues souhaitées, à l'aide des éléments label. L'ordre de présentation des items de la liste sera l'ordre de leur présence dans le fichier qui spécifie le formulaire.

    En résumé, s'il y a un sous-élément items, ce sont ces items qui sont offerts dans la liste, sinon ce sont les valeurs contenues dans le champ identifié par l'attribut field.

4.2.1) Filtrer une liste

Parfois, ce ne sont pas toutes les valeurs d'un champ que l'on veut voir dans la liste, mais seulement celles qui correspondent à certains critères. Par exemple, si on a un formulaire de recherche que l'on veut utiliser seulement pour les unités documentaires qui ont une ou des images associées, une liste de valeurs de l'élément persname (par exemple) ne serait pas intéressante car elle présenterait toutes les valeurs, pas seulement celles qui correspondent à des unités documentaires illustrées.

C'est pourquoi il est possible de filtrer les listes de valeurs en fonction d'un certain nombre de critères de filtres. Pour ce faire, il suffit d'ajouter un élément filters à l'intérieur de l'élément key spécifiant un critère de type liste, comme dans l'exemple (incomplet quant à la définition de la liste elle-même) suivant :


<key type="list" ...>
  ...
  <filters>
    <filter field="object" value="1"/>
    <filter field="unitid" value="400AP*"/>
  </filters>
</key>

Dans cet exemple, deux filtres sont définis, un indiquant que le champ object doit avoir la valeur 1 (présence d'une illustration dans l'unité documentaire) ET que la cote doit débuter par 400AP. On peut donc mettre plusieurs filtres, et ceux-ci sont reliés nécessairement par un ET booléen. Un filtre doit nécessairement être composé d'un champ et d'une valeur.

4.2.2) Filtres implicites

Lorsque vous associez un formulaire de recherche à un document EAD, lorsqu'un utilisateur affiche ce formulaire depuis la fenêtre de consultation de ce document, un filtre implicite sera ajouté pour rechercher uniquement dans les unités documentaires de ce document. Mais aussi, les éventuelles listes dans le formulaire seront automatiquement filtrées en fonction de ce critère (appartenance au document EAD), en plus de tout autre filtre que vous avez explicitement déclaré.

C'est pourquoi il est inutile de définir des filtres pour un document EAD dans un formulaire, car PLEADE le fera pour vous. Par conséquent, il est tout à fait possible d'utiliser un même formulaire de recherche pour plusieurs documents EAD, sans modifier les spécifications de ce formulaire. C'est le contexte d'appel qui permettra à PLEADE de déterminer quel filtre implicite utiliser.

Les filtres implicites sont également utilisés par PLEADE lorsqu'un formulaire de recherche est associé à un sous-ensemble de documents, une rubrique du système d'organisations. Ainsi, lorsqu'un utilisateur passe par cette rubrique et qu'il voit un formulaire de recherche, un filtre implicite sera ajouté pour que les unités retrouvées proviennent toujours de documents appartenant à cette rubrique.

4.3) boolean = critère booléen

Un critère booléen permet à l'utilisateur de chercher aisément dans un champ une valeur prédéterminée, ou encore de ne pas inclure ce critère de recherche. Il se présente toujours avec une case à cocher et un libellé. Si la case à cocher, le critère fera partie de la requête. Voici un exemple complet de critère booléen  :


<key
     type="boolean"
     connector="3"
     field="object"
     value-on="1"
     default="on|off"
     placement="right|left"
>
  <label xml:lang="fr">Unités illustrées seulement</label>
  <label xml:lang="en">Only illustrated units</label>
</key>


Voici la signification des différents attributs :

  • field indique le champ de recherche.

  • value-on indique la valeur à rechercher dans le champ, si la case est cochée par l'utilisateur.

  • default indique si la case à cocher doit être présentée cochée (on) ou pas (off) lorsque le formulaire est affiché. Cet attribut est optionnel et la valeur par défaut est off.

  • placement indique si la case à cocher doit être à gauche (left) du libellé ou à droite (right). Cet attribut est optionnel et la valeur par défaut est left.

4.4) hidden = critère caché

Un critère caché est un critère de recherche que l'utilisateur ne verra pas lorsque le formulaire sera affiché. Cela permet de prédéterminer des critères de recherche. Voici un exemple complet d'utilisation des critères cachés  :


<key type="hidden" field="unitid" value="400AP*"/>

Dans cet exemple, l'attribut field permet d'identifier le champ de recherche alors que l'attribut value permet d'indiquer la valeur à chercher. A noter que plusieurs champs cachés peuvent être placés dans un formulaire. Ils sont toujours reliés aux autres critères par un opérateur booléen ET.

Il est important aussi de rappeler que ce critère caché n'est pas totalement invisible pour l'utilisateur. En effet, celui-ci peut le constater d'au moins 3 façons :

  1. S'il regarde la source de la page HTML où se trouve le formulaire, car il apparaît sous la forme d'un champ HTML caché.

  2. S'il regarde l'URL de la recherche effectuée avec le formulaire, car le nom du champ et sa valeur y figurent.

4.5) date = critère de date

Dans PLEADE, certains champs de recherche sont de type date, ce qui permet notamment d'y faire des requêtes par intervalle de dates. C'est pourquoi nous proposons ce critère de date, qui permettra non seulement d'effectuer de telles recherches, mais aussi de bien gérer la validation des dates saisies ou encore le nombre de critères à afficher.

Pour bien expliquer le comportement de la recherche par date, nous allons prendre un cas simple : une unité de description dans un document EAD possède un élément unitdate exprimé ainsi :


<unitdate normal="1700/1750">1700 à 1750</unitdate>

Devant un tel élément, PLEADE va remplir deux champs de date pour cette unité documentaire :

  1. Le champ bdate (begin date, date de début), aura la valeur 1700.

  2. Le champ edate (end date, date de fin), aura la valeur 1750.

Ensuite, on voudrait que les utilisateurs puissent exprimer des requêtes sur les dates telles que :

  • 1725 : dans ce cas cette unité devra être retournée

  • 1760 : dans ce cas cette unité ne sera bien sûr pas retournée

  • Entre 1650 et 1800 : dans ce cas cette unité sera retournée

  • Entre 1725 et 1800 : dans ce cas elle sera aussi retournée

Pour atteindre cet objectif, des critères de type date pourront être inclus dans les formulaires de recherche. Ces critères devront nécessairement opérer sur des champs de type dates, ce qui n'est pas vérifié par le mécanisme de fabrication des formulaires et qui est donc à la charge de l'administrateur.

Voici un exemple complet d'un critère de type date :


<key
     type="date"
     connector="3"
     field="bdate,edate"
     format="\d\d\d\d,\d\d\d\d"
>
  <label xml:lang="fr">Unités illustrées seulement</label>
  <label xml:lang="en">Only illustrated units</label>
  <label-begin xml:lang="fr">De :</label-begin>
  <label-begin xml:lang="en">From:</label-begin>
  <label-end xml:lang="fr">A :</label-end>
  <label-end xml:lang="en">To:</label-end>
</key>


Dans cet exemple, voici la signification des différents attributs :

  • field : spécifie le ou les champs de recherche. Si on veut chercher dans une paire de champs de recherche (comme les champs date de début et date de fin), on doit les séparer par une virgule (sans espace), et le champ qui signifie date de début doit être le premier. Si veut chercher dans un seule champ, alors on indique seulement ce champ, et la valeur de la date cherchée devra être exacte. Cet attribut est bien sûr obligatoire.

  • format indique le format de date à respecter pour l'utilisateur. Ce format est indiqué sous la forme d'une expression régulière acceptée par le langage Javascript. Les valeurs possibles sont \d\d\d\d pour une année sur quatre chiffres, \d\d\d\d-\d\d-\d\d pour une date complète année-mois-jour, ou encore \d\d\d\d-\d\d pour une année et un mois. Cette indication sera utilisée pour alerter l'utilisateur que la date saisie n'est pas valide.

Par ailleurs, on remarque que ce critère supporte un sous-élément label pour indiquer l'intitulé placé devant le champ. Mais on peut aussi associer des sous-éléments label-begin et label-end pour indiquer respectivement le texte à placer devant la zone de saisie de la date de début ou de la date de fin. On peut ne pas inclure ces intitulés si l'on ne souhaite pas donner d'indication.


© 2003, 2004, 2005 PLEADE / AJLSM / Anaphore
Des questions ? Des remarques ? Utilisez les listes de discussions ! Vous voulez l'utiliser ? Vous pouvez le télécharger !