On peut individualiser les collections pour rendre accessibles les informations qu'elles contiennent de diverses manières. Le présent chapitre décrit la manière dont Greenstone extrait l'information des documents et la présente à l'utilisateur: le traitement des documents (section plugins), les structures de classification (section classifiers), et les outils d'interface utilisateur (sections formatting_greenstone_output et controlling_the_greenstone_user_interface).

Les greffons analysent les documents importés et en extraient les méta-données. Par exemple, le greffon HTML convertit des pages HTML en format d'archivage de Greenstone et extrait les méta-données explicites dans le format de document – telles que les titres, entourés de balises <title></title>.

Les greffons sont écrits en Perl. Ils sont tous inspirés d'un greffon de base appelé BasPlug, qui effectue les opérations partout nécessaires, telles que créer un nouveau document d'archive de Greenstone avec lequel travailler, affecter un identifiant d'objet (OID), et gérer les sections d'un document. Les greffons se trouvent dans le répertoire perllib/plugins.

Pour en savoir plus sur un greffon particulier, tapezpluginfo.pl nom-de-greffonà l'invite de commandes (il vous faudra d'abord invoquer le script de réglages approprié si vous ne l'avez pas encore fait, et sous Windows il vous faudra taper perl -S pluginfo.pl plugin-name si votre environnement n'est pas réglé pour associer les fichiers se terminant en .pl à l'interpréteur Perl). Ceci affichera des informations relatives au greffon à l'écran – les options spécifiques qu'il accepte, et quelles options générales sont autorisées.

On peut facilement écrire de nouveaux greffons qui traitent des formats de documents non couverts par les greffons existants, mettent les documents en forme d'une manière particulière, ou extraient un nouveau type de méta-données.

La table <tblref table_options_applicable_to_all_plugins> montre les options acceptées par tout greffon héritant de BasPlug.

<tblcaption table_options_applicable_to_all_plugins|Options valables pour tous les greffons></tblcaption>

<tblcaption table_greenstone_plugins|Greffons (plugins) de Greenstone></tblcaption>

Les greffons de traitement de documents sont utilisés par le logiciel de construction de collection pour analyser chaque document source d'une manière qui dépend de son format. Le fichier de configuration d'une collection liste tous les greffons utilisés lors de sa construction. Lors de l'opération d'import, chaque fichier ou chaque répertoire est passé tour à tour à tous les greffons jusqu'à ce qu'un greffon soit trouvé qui puisse traiter l'objet – c'est pourquoi les premiers greffons listés ont la priorité sur des greffons apparaissant plus tard dans la liste. Si aucun greffon ne peut traiter le fichier, un avertissement est affiché (sur la sortie d'erreur standard) et le traitement passe au fichier suivant (c'est pourquoi l'option block_exp peut être utile – pour éviter ces messages d'erreur dans le cas de fichiers qui sont peut-être présents mais n'ont pas besoin d'être traités). Lors de la construction, on utilise la même procédure, mais c'est le répertoire archives qui est traité en lieu et place du répertoire import.

Les greffons standard de Greenstone sont listés table <tblref table_greenstone_plugins>. Il est nécessaire d'utiliser un processus récursif pour traverser des hiérarchies de répertoires. Bien que les programmes d'import et de construction n'effectuent pas de récursion explicite, certains greffons provoquent une récursion indirecte en passant des noms de fichiers ou de répertoires dans le pipe-line des greffons. Par exemple, la manière habituelle d'opérer récursivement à travers une hiérarchie de répertoire est de spécifier RecPlug, qui travaille exactement ainsi. S'il est présent, il devrait être en dernière position dans le pipe-line. Seuls les deux premiers greffons de la table <tblref table_greenstone_plugins> provoquent une récursion indirecte.

Certains greffons sont écrits pour des collections spécifiques, avec un format de document que l'on ne trouve nulle part ailleurs, tel que le texte électronique utilisé dans la collection Gutenberg. Ces greffons spécifiques à une collection se trouvent dans le répertoire perllib/plugins de la collection. On peut utiliser des greffons spécifiques à une collection pour remplacer des greffons généraux portant le même nom, qui ne seront alors pas appelés.

Certains greffons de traitement de documents utilisent des programmes externes qui analysent des formats de fichiers propriétaires spécifiques – tel que par exemple Microsoft Word – et les transforment en texte brut ou en HTML. Un greffon général appelé ConvertToPlug invoque le programme de conversion approprié et en passe le résultat aux greffons TEXTPlug ou HTMLPlug. Nous décrirons cette opération plus en détail sous peu.

Certains greffons disposent d'options individuelles, qui les contrôlent de manière plus fine que ce que permettent les options générales. C'est la table <tblref table_plugin-specific_options> qui décrit ces options individuelles.

<tblcaption table_plugin-specific_options|Options propres aux greffons></tblcaption>

| title_sub | Expression de substitution Perl pour modifier les titres. |

Les formats propriétaires posent des problèmes difficiles pour tout système de bibliothèque numérique. Bien qu'ils soient parfois documentés, ils sont susceptibles de changer sans préavis, et il est difficile de suivre le rythme des changements. Greenstone a fait le choix d'utiliser des outils de conversion publiés selon les termes de la GPL (licence publique générale de GNU) par des gens focalisés sur telle ou telle tâche de conversion. Les outils pour convertir les formats Word et PDF sont inclus dans le répertoire packages. Tous convertissent des documents au format texte ou au format HTML. Les greffons HTMLPlug et TEXTPlug prennent ensuite la relève et convertissent ce résultat intermédiaire au format d'archivage de Greenstone. C'est ConvertToPlug qui est utilisé pour inclure les outils de conversion. BasPlug n'est jamais appelé directement, mais les greffons traitant des formats particuliers en héritent, comme illustré figure <imgref figure_plugin_inheritance_hierarchy>. ConvertToPlug utilise le système d'héritage dynamique de Perl pour hériter soit de TEXTPlug soit de HTMLPlug, selon le format dans lequel le document source a été converti.

<imgcaption figure_plugin_inheritance_hierarchy|%!– id:537 –%Hiérarchie d'héritage des greffons (plugins) ></imgcaption>

Quand ConvertToPlug reçoit un document, il appelle gsConvert.pl (qui se trouve dans le répertoire GSDLHOME/bin/script) pour invoquer l'outil de conversion approprié. Après conversion, le document est renvoyé vers le greffon ConvertToPlug, qui invoque ensuite le greffon texte ou HTML, selon les cas. Tout greffon héritant de ConvertToPlug dispose d'une option convert_to (convertit vers), dont l'argument est soit text (texte) soit html, pour spécifier le format intermédiaire préféré. Le format texte est plus rapide, mais le format HTML rend mieux en général, et comprend des images.

Il existe parfois plusieurs outils de conversion pour traiter un format particulier, et le programme gsConvert peut en essayer plusieurs sur un document donné. Par exemple, l'outil habituel de conversion du format Work, wvWare, ne traite pas les formats antérieurs à Word 6, et c'est un programme appelé AnyToHTML, qui se contente d'extraire toutes les chaînes de texte qu'il peut trouver, qui est appelé pour convertir les documents au format Word 5.

Voici les étapes nécessaires pour ajouter un nouvel outil externe de conversion de document:

1. Installez le nouvel outil de conversion de manière qu'il soit accessible à Greenstone (placez-le dans le répertoire packages).
2. Modifiez gsConvert.pl pour utiliser le nouvel outil de conversion. Il s'agit d'ajouter une nouvelle clause à l'instruction if de la fonction main, et d'ajouter une fonction qui appelle l'outil de conversion.
3. Écrivez un greffon de premier niveau qui hérite de ConvertToPlug pour intercepter le format et le passer à la suite de la chaîne.

Le greffon standard RecPlug incorpore également une méthode pour positionner des méta-données dans les documents de manière manuelle (ou automatique) à partir de fichiers XML créés manuellement (ou automatiquement). Nous détaillons quelque peu ceci, de manière que vous puissiez créer des fichiers de méta-données dans le format approprié. Si l'option use_metadata_files est précisée, RecPlug utilise un fichier de méta-données auxiliaire, metadata.xml. La première partie de la figure <imgref figure_xml_format> illustre la définition de type de document (DTD) XML pour le format du fichier de méta-données, et la deuxième partie de la figure <imgref figure_xml_format_1> montre un exemple de fichier metadata.xml.

<imgcaption figure_xml_format|%!– id:547 –%(a) %!– id:546 –%Format XML: (a) Définition de type de document (DTD); (b) Fichier de méta-données d'exemple ></imgcaption>

<!DOCTYPE GreenstoneDirectoryMetadata [
   <!ELEMENT DirectoryMetadata (FileSet*)>
   <!ELEMENT FileSet (FileName+,Description)>
   <!ELEMENT FileName (#PCDATA)>
   <!ELEMENT Description (Metadata*)>
   <!ELEMENT Metadata (#PCDATA)>
   <ATTLIST Metadata name CDATA #REQUIRED>
   <ATTLIST Metadata mode (accumulate|override) "override">
]>

<imgcaption figure_xml_format_1|%!– id:549 –%(b) %!– id:548 –% ></imgcaption>

<?xml version="1.0" ?>
<!DOCTYPE GreenstoneDirectoryMetadata SYSTEM
"http://greenstone.org/dtd/GreenstoneDirectoryMetadata/<br/>1.0/GreenstoneDirectoryMetadata.dtd">
<DirectoryMetadata>
   <FileSet>
       <FileName>nugget.*</FileName>
       <Description>
       <Metadata name="Title">Nugget Point Lighthouse</Metadata>
           <Metadata name="Place" mode="accumulate">Nugget Point</Metadata>
       </Description>
   </FileSet>
   <FileSet>
       <FileName>nugget-point-1.jpg</FileName>
       <Description>
           <Metadata name="Title">Nugget Point Lighthouse , The Catlins </Metadata>
           <Metadata name="Subject">Lighthouse</Metadata>
       </Description>
   </FileSet>
</DirectoryMetadata>

Le fichier d'exemple contient deux structures de méta-données. Dans chacune, l'élément filename décrit les fichiers auxquels les méta-données s'appliquent, sous la forme d'une expression rationnelle. <FileName>nugget.*</FileName> indique ainsi que le premier enregistrement de méta-données s'applique à tous les fichiers dont le nom commence par «nugget»¹⁾. Pour ces fichiers, la méta-donnée Title vaudra «Phare de Nugget Point».

Les éléments de méta-données sont traités dans l'ordre dans lequel ils apparaissent. La deuxième structure de la figure 10 positionne la méta-donnée Title pour le fichier nugget-point-1.jpg à la valeur «Phare de Nugget Point, Catlins», en écrasant la spécification précédente. Elle ajoute également un champ Subject dans les méta-données.

Parfois, les méta-données sont multi-valuées et les nouvelles valeurs devraient s'accumuler au lieu d'écraser les précédentes. L'attribut mode=accumulate a cet effet. Il est appliqué à la méta-donnée Place (lieu) dans la première spécification de la figure 10, cette méta-donnée sera donc multi-valuée. Pour revenir à une méta-donnée simple, écrivez<Metadata name="Place" mode="override">Nouvelle-Zélande</Metadata>En fait, on peut négliger de préciser cette spécification de mode puisque tout élément écrase le précédent par défaut, sauf indication contraire. Pour accumuler les méta-données dans un champ particulier, il faut préciser mode=accumulate à chaque occurrence.

Quand son option use_metadata_files est activée, le greffon RecPlug recherche dans chaque répertoire en entrée un fichier XML appelé metadata.xml et applique son contenu à tous les fichiers et sous-répertoires du répertoire courant.

Le mécanisme metadata.xml instancié dans le greffon RecPlug n'est qu'une manière de spécifier des méta-données pour des documents. Il est facile d'écrire des greffons différents qui accepteront des spécifications de méta-données dans des formats complètement différents.

Il faut souvent structurer les documents source en sections et sous-sections, et donc communiquer cette information à Greenstone de manière qu'il puisse reproduire la structure hiérarchique du document. On peut aussi associer à chaque section et sous-section des méta-données, et en particulier un titre.

La manière la plus simple de procéder est souvent d'éditer les fichiers source, tout simplement. Le greffon HTML dispose d'un option description_tags qui traite les balises dans le texte comme suit:

<!--
<Section>
   <Description>
       <Metadata name="Title"> Realizing human rights for poor people: Strategies for achieving the international development targets</Metadata>
   </Description>
-->

(texte de la section)

<!--
</Section>
-->

On utilise les marqueurs%!– … –%car ils dénotent des commentaires en HTML; ces balises de section n'auront donc aucun impact sur la mise en forme du document. On peut spécifier d'autres types de méta-données dans la portion Description, mais ce n'est pas le cas du style de collection décrit ici. On peut aussi imbriquer des balises, de telle sorte que la ligne(texte de la section)ci-dessus peut elle-même inclure des sous-sections, telles que

(texte de la première partie de la section)

<!--
<Section>
   <Description>
       <Metadata name="Title"> The international development targets</Metadata>
   </Description>
-->

(texte de la sous-section)

<!--
</Section>
-->

(texte de la dernière partie de la section)

Cette fonctionnalité est héritée par tout greffon utilisant HTMLPlug. En particulier, le greffon Word convertit les données qu'il reçoit au format HTML: on peut donc procéder exactement de la même manière pour spécifier des méta-données dans les fichiers Word (et RTF). Ceci implique un peu de travail en coulisses, puisque lors de la conversion de documents Word vers HTML, le programme prend soin, normalement, de neutraliser les caractères significatifs pour HTML, tels que<et>; nous nous sommes arrangés pour contourner cette neutralisation dans le cas des spécifications mentionnées ci-dessus. Il faut alors utiliser exactement le même format, même dans des fichiers Word, et ne pas oublier les%!–et–%qui entourent les méta-données. Le choix des polices et l'espacement n'ont aucune importance.

Les classificateurs servent à créer les index de navigation d'une collection, comme par exemple l'index titres A-Z de la collection dlpeople, et les index thème, comment faire, organisation et titres A-Z dans la bibliothèque de développement pour l'humanité, dont la collection «Demo» est un sous-ensemble. La barre de navigation située au sommet des copies d'écran dans les figures 3 et 8a inclut la fonction Rechercher, qui est toujours disponible, suivie par autant de boutons que de classificateurs définis. Les informations servant à la navigation sont stockées dans la base de données d'informations de la collection, et y sont placées par des classificateurs lors de la phase finale du programme buildcol.pl.

<imgcaption figure_azlist_classifier|%!– id:566 –%ClassificateurAZList ></imgcaption>

Les classificateurs, à l'instar des greffons, sont spécifiés dans le fichier de configuration de la collection. À chacun correspond une ligne débutant par le mot-clef classify et suivie du nom du classificateur et des options qu'il accepte. Le fichier de configuration de collection simple étudié dans la section configuration_file comprend la ligne classify AZList -metadata Title, qui crée une liste alphabétique des titres en prenant tous les documents pourvus d'un champ de méta-données Title, en triant ces derniers et en les ventilant en intervalles alphabétiques. On trouvera un exemple dans la figure <imgref figure_azlist_classifier>.

<imgcaption figure_list_classifier|%!– id:568 –%ClassificateurList ></imgcaption>

Un classificateur plus simple, appelé List, et illustré dans la figure <imgref figure_list_classifier>, crée une liste triée d'une méta-donnée spécifiée et l'affiche sans créer de tranches alphabétiques. Un exemple est la méta-donnée how to de la collection «Demo», qui est produite par la ligne classify List -metadata Howto dans le fichier de configuration de la collection²⁾. Un autre classificateur de liste générique est DateList, illustré dans la figure <imgref figure_datelist_classifier>, qui engendre une liste de sélection d'intervalles de dates (le classificateur DateList est également utilisé dans la collection «Archives» de Greenstone).

<imgcaption figure_datelist_classifier|%!– id:570 –%ClassificateurDateList ></imgcaption>

D'autres classifications engendrent des structures de navigation qui sont explicitement hiérarchiques. Les classifications hiérarchiques sont utiles pour des classifications et sous-classifications de thèmes, et les hiérarchies organisationnelles. Le fichier de configuration de la collection «Demo» contient la ligne classify Hierarchy -hfile sub.txt -metadata Subject -sort Title, et la figure <imgref figure_hierarchy_classifier> ontre la hiérarchie de thèmes que cette ligne produit. L'étagère portant un titre en gras et l'étagère actuellement utilisée; la classification de thème à laquelle elle appartient la surplombe. Dans cet exemple la hiérarchie utilisée pour la classification est stockée dans un simple fichier texte, sous le nom sub.txt.

<imgcaption figure_hierarchy_classifier|%!– id:572 –%ClassificateurHierarchy ></imgcaption>

Tous les classificateurs génèrent une structure hiérarchique qui est utilisée pour afficher un index de navigateur. Les niveaux les plus bas de la hiérarchie (les feuilles) sont généralement les documents, mais dans certains classificateurs ce sont les sections. Les noeuds internes de la hiérarchie sont Vlist, Hlist, ou Datelist. Un noeud Vlist est une liste d'objets affichés verticalement et descendant la page, telle que l'index «comment faire» de la collection «Demo» (figure <imgref figure_list_classifier>). Un noeud Hlist est affiché horizontalement; par exemple l'affichage AZList de la figure <imgref figure_azlist_classifier> est une hiérarchie à deux niveaux de noeuds internes consistant en un noeud Hlist (donnant le sélecteur A-Z) et dont les enfants sont des noeuds Vlist – parents, à leur tour, de documents. Un noeud Datelist (figure <imgref figure_datelist_classifier>) est un cas particulier de noeud Vlist qui permet d'effectuer des sélections par année et par mois.

Les lignes spécifiant des classificateurs dans les fichiers de configuration de collection contiennent un argument metadata qui identifie les méta-données selon lesquelles classifier et trier les documents. Tout document de la collection ne disposant pas de cette méta-donnée sera omis par le classificateur (mais il sera quand même indexé, et les recherches le prendront donc en compte). En l'absence de spécification d'argument metadata, tous les documents sont inclus dans le classificateur, dans l'ordre dans lequel le processus de construction les a trouvés. C'est utile si vous souhaitez obtenir une liste de tous les documents de votre collection.

<tblcaption table_greenstone_classifiers|Classificateurs de Greenstone></tblcaption>

Les classificateurs actuellement disponibles sont listés dans la table <tblref table_greenstone_classifiers>. De même que l'on peut utiliser le programme pluginfo.pl pour en savoir plus sur un greffon quelconque, on peut utiliser le programme classinfo.pl pour en savoir plus sur un classificateur et sur les options qu'il propose.

Tous les classificateurs acceptent l'argument buttonname, qui définit ce qui est écrit sur le bouton de navigation de Greenstone qui invoque le classificateur (sa valeur par défaut est le nom de l'argument metadata). Des boutons sont fournis pour chacun des types de méta-données du système Dublin Core, ainsi que pour quelques autres types de méta-données.

Chaque classificateur reçoit un nom implicite en fonction de sa position dans le fichier de configuration. Par exemple, le troisième classificateur spécifié dans le fichier s'appellera CL3. Ces noms sont utilisés dans les champs de la base de données d'informations de la collection, qui définit la hiérarchie des classificateurs.

On peut écrire des classificateurs propres à une collection; ils sont alors stockés dans son répertoire perllib/classify. La bibliothèque de développement pour l'humanité dispose d'un classificateur propre de collection qui s'appelle HDLList, et qui est une variante mineure d'AZList.

Voici les différentes possibilités de classificateurs de listes:

• SectionList – comme List mais les feuilles sont des sections et non pas des documents. Toutes les sections du document sont incluses à l'exception des sections de premier niveau. Cela sert à créer des listes de sections (ou d'articles, de chapitres, ou …) cVoici les différentes omme dans la collection Computists' Weekly (l'hebdomadaire des informaticiens), disponible depuis le site webnzdl.org, dont chaque numéro est un unique document qui comprend plusieurs dépêches indépendantes, chacune étant placée dans sa propre section.
• AZList – génère une hiérarchie à deux niveaux comprenant un noeud HList dont les enfants sont des noeuds VList, parents à leur tour de documents. Le noeud HList est un sélecteur A-Z qui divise les documents en intervalles alphabétiques. Les documents sont triés alphabétiquement selon des méta-données, et la liste résultante est ventilée en intervalles.
• AZSectionList – comme AZList, mais les feuilles sont des sections, et non pas des documents.
• DateList – comme AZList à ceci près que le noeud HList de premier niveau permet des sélections par année et que ses enfants sont des noeuds de type DateList et non pas de type VList. La valeur par défaut de l'argument metadata est Date.

Tous les classificateurs sont hiérarchiques. Cependant, les classificateurs de la section 2.1.1 disposent d'un nombre fixé de niveaux, alors que le classificateur hierarchy décrit dans la présente section peut créer un nombre de niveaux arbitraire: il est plus complexe à spécifier que les classificateurs de listes.

<imgcaption figure_part_of_the_file_sub|%!– id:618 –%Portion du fichier sub.txt ></imgcaption>

1           1       "General reference"
1.2       1.2       "Dictionaries, glossaries, language courses, terminology
2           2       "Sustainable Development, International cooperation, Pro
2.1       2.1       "Development policy and theory, international cooperatio
2.2       2.2       "Development, national planning, national plans"
2.3       2.3       "Project planning and evaluation (incl. project managem
2.4       2.4       "Regional development and planning incl. regional profil
2.5       2.5       "Nongovernmental organisations (NGOs) in general, self-
2.6       2.6       "Organisations, institutions, United Nations (general, d
2.6.1   2.6.1       "United Nations"
2.6.2   2.6.2       "International organisations"
2.6.3   2.6.3       "Regional organisations"
2.6.5   2.6.5       "European Community - European Union"
2.7       2.7       "Sustainable Development, Development models and example
2.8       2.8       "Basic Human Needs"
2.9       2.9       "Hunger and Poverty Alleviation"

L'argument hfile donne le nom d'un fichier, tel que celui de la figure <imgref figure_part_of_the_file_sub>, qui définit la hiérarchie de méta-données. Chaque ligne décrit une classification, et les descriptions comptent trois parties:

• Un identifiant, qui fait correspondre la valeur de la méta-donnée (donnée par l'argument metadata) à la classification.
• Un marqueur de position dans la hiérarchie, sous forme numérique en plusieurs parties, comme par exemple 2, 2.12, 2.12.6.
• Le nom de la classification (s'il contient des espaces, il faut le placer entre apostrophes doubles).

La figure <imgref figure_part_of_the_file_sub> est une portion du fichier sub.txt, utilisé pour créer la hiérarchie de thèmes dans la bibliothèque de développement pour l'Humanité (et dans la collection «Demo»). Cet exemple n'est pas très clair puisque le nombre représentant la hiérarchie apparaît deux fois sur chaque ligne. Le type de méta-donnée Hierarchy est représenté dans les documents avec des valeurs sous forme numérique hiérarchique, ce qui correspond à la première occurrence. C'est la deuxième occurrence qui est utilisée pour déterminer la hiérarchie implémentée dans la hiérarchie de navigation.

Le classificateur hierarchy dispose d'un argument facultatif, sort, qui détermine la manière dont les documents sont ordonnés au niveau des feuilles. On peut spécifier n'importe quelle méta-donnée comme clef de tri. Le comportement par défaut est de produire la liste dans l'ordre dans lequel le processus de construction rencontre les documents. Au niveau des noeuds internes, l'ordre est déterminé par celui des spécifications dans l'argument hfile.

Les classificateurs sont des objets Perl, héritant de BasClas.pm, et stockés dans le répertoire perllib/classify. Ils sont utilisés lors de la construction de la collection. Leur exécution se fait en quatre étapes:

1. La méthode new crée l'objet classificateur.
2. La méthode init initialise l'objet avec des paramètres tels que le type de méta-donnée, le nom du bouton, et le critère de tri.
3. La méthode classify est invoquée une fois par document, et stocke les informations de la classification effectuée dans l'objet classificateur.
4. La méthode get_classify_info renvoie la classification stockée localement vers le processus de construction, qui l'écrit à son tour dans la base de données d'informations de la collection à des fins d'utilisation lors de l'affichage de la collection, au moment de l'exécution.

La méthode classify rapatrie l'OID de chaque document, la valeur de méta-donnée selon laquelle classifier le document, et, si nécessaire, la valeur de méta-donnée selon laquelle trier les documents. La méthode get_classify_info s'occupe du tri et de tout traitement propre au classificateur. Dans le cas du classificateur AZList par exemple, elle ventile la liste en intervalles.

Le processus de construction initialise les classificateurs dès que l'objet builder est construit. Les classifications sont créées pendant la phase de construction, lors de la création de la base de données d'informations, par classify.pm, qui réside dans le répertoire perllib de Greenstone.

<tblcaption table_items_appearing_in_format_strings|Objets apparaissant dans les chaînes de formatage></tblcaption>

Les pages web que vous pouvez voir lorsque vous utilisez Greenstone ne sont stockées nulle part; elles sont générées «à la volée» en fonction des besoins. L'apparence de nombreux aspects de ces pages est contrôlée à l'aide de «chaînes de formatage» (dans le sens de «mise en forme», et pas de «remise à zéro»). Les chaînes de formatage se trouvent dans le fichier de configuration de la collection, introduites par le mot-clef format lui-même suivi du nom de l'élément concerné par la mise en forme. Il existe deux types d'éléments de page contrôlés par des chaînes de formatage. Le premier comprend les éléments de la page qui affichent des documents ou des portions de documents. Le second comprend les listes produites par les classificateurs et les recherches. Toutes les chaînes de formatage sont interprétées au moment de l'affichage des pages. Elles prennent donc effet dès que le fichier collect.cfg est modifié et sauvegardé; il est par conséquent rapide et facile de faire des expériences avec les chaînes de formatage.

La table <tblref table_items_appearing_in_format_strings> montre les instructions qui affectent la représentation des documents. L'option DocumentButtons contrôle les boutons qui sont affichés sur une page de document. Ici, chaîne est une liste de boutons (séparés par|), dont les valeurs possibles sont Detach (détacher), Highlight (mettre en valeur), Expand Text (développer le texte), et Expand Contents (développer la table des matières). Modifier l'ordre de la liste a le même effet sur les boutons.

<tblcaption table_the_format_options|Les options du mot-clefformat></tblcaption>

Les chaînes de formatage qui contrôlent l'apparence des listes peuvent s'appliquer à divers niveaux de la structure d'affichage. Elles peuvent altérer toutes les listes d'un certain type au sein d'une collection (comme par exemple DateList), toutes les parties d'une liste (comme par exemple toutes les entrées de la liste Rechercher), ou des portions spécifiques d'une liste particulière (comme par exemple la portion verticale de la liste du classificateur AZList appliqué sur des titres).

Le mot-clef format précède un mot-clef en deux parties, dont une seule est obligatoire. La première partie identifie la liste où s'applique le format. La liste générée par une recherche s'appelle Search (rechercher), tandis que les listes générées par des classificateurs sont appelées CL1, CL2, CL3,… pour respectivement le premier, le deuxième, le troisième… classificateur spécifié dans le fichier collect.cfg. La deuxième partie du mot-clef est la portion de la liste à laquelle appliquer la mise en forme – soit HList (pour une liste horizontale, telle que le sélecteur dans un noeud AZList), VList (pour une liste verticale, telle que la liste des tous les titres sous un noeud de type AZList), ou DateList. Par exemple:

format CL4VList … s'applique à tous les VList de CL4

format CL2HList … s'applique à tous les HList de CL2

format CL1DateList … s'applique à tous les DateList de CL1

format SearchVList … s'applique à la liste de Résultats de la recherche

format CL3 … s'applique à tous les noeuds de CL3, sauf indication contraire

format VList … s'applique à tous les VList de tous les classificateurs, sauf indication contraire

Les"…"de ces exemples représentent des spécifications de formatage HTML qui contrôlent l'information et sa représentation, apparaissant sur des pages web représentant le classificateur. Comme pour les spécifications HTML, toute méta-donnée peut apparaître entre crochets: sa valeur est interpolée à l'endroit indiqué. Tout élément de la table <tblref table_the_format_options> peut également apparaître dans des chaînes de formatage. La syntaxe des chaînes prévoit également une instruction conditionnelle, qui est illustrée plus bas.

Rappelez-vous que tous les classificateurs produisent des hiérarchies. Chaque niveau de la hiérarchie est affiché de l'une de quatre manières possibles. Nous avons déjà mentionné HList, VList, et DateList. Il existe également Invisible, qui est la manière dont les tous premiers niveaux des hiérarchies sont représentés – le nom du classificateur apparaît déjà séparément, en effet, sur la barre de navigation de Greenstone.

<imgcaption figure_excerpt_from_the_demo_collection_collect|%!– id:674 –%Extrait du fichier collect.cfg de la collection «Demo» %!– withLineNumber –%></imgcaption>

classify Hierarchy -hfile sub.txt -metadata Subject -sort Title
classify AZList       -metadata Title
classify Hierarchy -hfile org.txt -metadata Organisation -sort Title
classify List           -metadata Howto
format SearchVList " <td valign=top [link][icon][/link]</td><td>{If}
                                       {[parent(All':'):Title],[parent(All':'):Title]:}
                                       [link][Title][/link]</td> "
format CL4Vlist                 "<br>[link][Howto][/link] "
format DocumentImages   true
format DocumentText       "<h3>[Title]</h3>\\n\\n<p>[Text]"
format DocumentButtons " Expand Text|Expand contents|Detach|Highlight"

La figure <imgref figure_excerpt_from_the_demo_collection_collect> représente une portion du fichier de configuration de la collection «Demo». Nous l'utilisons comme exemple, car il comprend plusieurs classificateurs avec un formatage riche. Remarquez que les instructions des fichiers de configuration ne peuvent pas contenir de retour à la ligne, et que dans la figure, nous avons scindé les lignes les plus longues pour des raisons de lisibilité.

La ligne 4 spécifie le classificateur How To (comment faire) de la collection «Demo». C'est le quatrième classificateur du fichier de configuration de la collection; on s'y réfère donc sous le nom CL4. L'instruction de formatage correspondante est la ligne 7 de la figure <imgref figure_excerpt_from_the_demo_collection_collect>. Cette information d'«indice» est engendrée par le classificateur List, et sa structure est la liste brute des titres affichés figure <imgref figure_list_classifier>. Les titres sont reliés aux documents eux-mêmes: cliquer sur un titre affiche le document correspondant. Les enfants du premier niveau de la hiérarchie sont affichés sous la forme d'une VList (liste verticale), qui liste les sections verticalement. Comme l'indique l'instruction format associée, chaque élément de la liste apparaît sur une nouvelle ligne ("<br>") et contient le texte de Howto, lui-même relié par lien hypertexte au document lui-même.

La ligne 1 spécifie la classification Subject (Thème) de la collection «Demo», à laquelle on se référera sous le nom CL1 (puisqu'elle est la première du fichier de configuration), et la ligne 3 spécifie la classification Organisation CL3. Toutes deux sont générées par le classificateur Hierarchy et comprennent donc une structure hiérarchique d'objets VList.

La ligne 2 spécifie la dernière classification de la collection «Demo», titres A-Z (CL2). Remarquez qu'il n'existe pas de chaînes de formatage associées aux classificateurs CL1 à CL3. Greenstone dispose de valeurs par défaut pour chaque type de chaîne de formatage; il n'est donc pas nécessaire de positionner une chaîne de formatage quand on ne souhaite pas obtenir un comportement différent du comportement par défaut.

<imgcaption figure_formatting_the_document|%!– id:679 –%Mise en forme du document ></imgcaption>

Voilà pour les quatre lignes classify de la figure <imgref figure_excerpt_from_the_demo_collection_collect>. On y trouve aussi quatre lignes format. Nous avons déjà expliqué la ligne CL4Vlist. Les trois lignes restantes sont du premier type de chaîne de formatage, documenté dans la table <tblref table_items_appearing_in_format_strings>. Par exemple, la ligne 8 place l'image de couverture en haut à gauche de chaque page de document. La ligne 9 formate le texte du document à proprement parler, et place le titre du chapitre ou de la section concernée juste avant le texte. Tous ces effets sont illustrés dans la figure <imgref figure_formatting_the_document>.

<imgcaption figure_formatting_the_search_results|%!– id:681 –%Mise en forme des résultats de la recherche ></imgcaption>

La ligne 5 de la figure <imgref figure_excerpt_from_the_demo_collection_collect> est une spécification quelque peu complexe qui formate la liste de résultats à une requête renvoyée par une recherche, dont les portions sont illustrées à la figure <imgref figure_formatting_the_search_results>. Voici une version simplifiée de la chaîne de formatage:

<td valign=top>[link][icon][/link]</td>
<td>[link][Title][/link]</td>

Ceci est conçu pour apparaître comme une ligne dans un tableau, ce qui est la manière dont la liste de résultats à une requête est mise en forme. Comme d'habitude, on obtient une petite icone cliquable qui mène au texte, et le titre du document, ancre d'un lien hypertexte qui mène au document à proprement parler.

Dans cette collection, les documents sont hiérarchiques. En fait, l'ancre de lien hypertexte ci-dessus se transforme en le titre de la section renvoyée par le requête. Il serait néanmoins préférable de lui adjoindre également le titre de la section qui la contient, du chapitre qui contient cette dernière, et du livre où ce chapitre apparaît. Il existe un objet de méta-donnée particulier, parent, qui n'est pas stocké dans les documents mais qui est implicite dans tout document hiérarchique, qui produit une telle liste. Elle renvoie soit le document parent ou, si elle est utilisée avec le qualificateur All (tout), la liste de tous les ancêtres au sens hiérarchique, séparés par une chaîne de caractères que l'on peut préciser après le qualificateur All. Ainsi:

<td valign=top>[link][icon][/link]</td> <br/><td>{[parent(All': '):Title]: }[link][Title][/link]</td>

a pour effet de produire une liste contenant le titre du livre, le titre du chapitre, etc., qui entourent la section cible; titres séparés par des caractères deux points, et un dernier caractère deux points est suivi d'un lien hypertexte menant au titre de la section cible.

Malheureusement, dans le cas où la cible est un livre, elle n'aura aucun parent et on verra donc apparaître une chaîne vide suivie d'un caractère deux points. Pour éviter de tels problèmes, on peut utiliser dans une chaîne de formatage des instructions conditionnelles if and or … else (si et ou … sinon):

{If}{[metadata], action-if-non-null, action-if-null}
{Or}{action, else another-action, else another-action, etc}

Dans chaque cas les accolades signalent que les instructions doivent être interprétées, et non pas simplement affichées comme du texte. L'instruction If teste si la méta-donnée est vide, et prend la première clause si ce n'est pas le cas, et la deuxième clause si c'est le cas (et si une deuxième clause est fournie). On peut utiliser tout élément de méta-données, y compris la méta-donnée spéciale parent. L'instruction Or évalue chaque action tour à tour jusqu'au moment où elle en rencontre une qui n'est pas vide. Cette action est alors renvoyée en sortie et le reste de la ligne est ignoré.

Si l'on revient à la ligne 5 de la figure <imgref figure_excerpt_from_the_demo_collection_collect>, la chaîne de formatage complète est:

<td valign=top>[link][icon][/link]</td>
<td>{If}{[parent(All': '):Title],
           [parent(All': '):Title]:}
      [link][Title][/link]</td>

Ceci fait précéder la spécification parent d'un test qui examine si le résultat est vide et n'affiche la chaîne du parent que lorsque ce dernier est présent. On peut aussi qualifier parent par Top (sommet) au lieu de All (tout), ce qui donne le nom de document de niveau le plus élevé qui entoure une section – dans le cas présent, le nom du livre. Nul besoin, avec Top, de chaîne de séparation.

Voici quelques derniers exemples pour illustrer d'autres fonctionnalités. Le classificateur DateList, dans la figure <imgref figure_datelist_classifier>, est utilisé dans la classification Dates de la collection Computists' Weekly (l'hebdomadaire des informaticiens), et il se trouve qu'il en est le deuxième classificateur, soit CL2. Le classificateur et les spécifications de formatage sont indiqués ci-dessous. Le classificateur DateList diffère d'AZList en ce sens qu'il trie toujours selon la méta-donnée Date, et que les branches situées au pied de la hiérarchie de navigation utilisent DateList au lieu de VList, ce qui ajoute à gauche des listes de documents, l'année et le mois.

classify AZSectionList metadata=Creator
format CL2Vlist "<td>[link][icon][/link]</td> <br/><td>[Creator]</td> <br/><td>&nbsp;&nbsp;[Title]</td> <br/><td>[parent(Top):Date]</td> "

La spécification de formatage affiche ces VLists de manière appropriée.

Le mécanisme de chaîne de formatage est souple mais difficile à apprendre. La meilleure manière de procéder est d'étudier des fichiers de configuration de collections existantes.

Utiliser le mécanisme[link] … [/link]dans une chaîne de formatage a pour effet d'insérer un lien hypertexte menant au texte du document, en version HTML. Il est utile dans certaines collections de pouvoir afficher d'autres versions du document. Dans une collection de documents au format Microsoft Word, par exemple, il est bon d'être capable d'afficher la version Word de chaque document plutôt que le HTML qui en fut extrait; de même pour des documents PDF.

Pour pouvoir afficher différentes versions d'un document, la clef est d'embarquer les informations nécessaires (c'est-à-dire où se trouvent les autres versions du document) dans le format d'archivage de Greenstone du document. On représente cette information sous la forme de méta-données. Souvenez-vous qu'en plaçant

[link][Title][/link]

dans une chaîne de formatage, on crée un lien vers la version HTML du document, lien dont l'ancre est le titre du document. Les greffons Word et PDF générent tous deux la méta-donnée srclink de telle sorte qu'écrire

[srclink][Title][/srclink]

dans une chaîne de formatage créera un lien vers la version Word ou PDF du document; lien dont l'ancre sera dans cet exemple aussi, le titre du document. Pour permettre d'afficher l'icone appropriée pour les documents Word et PDF, ces greffons générent aussi la méta-donnée srcicon de telle sorte que

[srclink][srcicon][/srclink]

créera un lien étiqueté par l'icone standard pour le format Word ou PDF (selon le cas), et non pas par le titre du document.

L'interface utilisateur de Greenstone est entièrement contrôlée par des macros placées dans le répertoire GSDLHOME/macros. Elles sont écrites dans un langage conçu spécialement pour Greenstone, et sont utilisées au moment de l'exécution pour engendrer des pages web. La traduction du langage de macros en HTML est la dernière étape de l'affichage d'une page. Ainsi, toute modification à un fichier de macros affecte immédiatement l'affichage, il est donc rapide et facile de faire des expériences avec les macros. Tous les fichiers de macros utilisés par Greenstone sont listés dans le fichier GSDLHOME/etc/main.cfg et sont chargés à chaque démarrage. Signalons l'exception de la version «Bibliothèque locale» sous Windows; dans ce cas il est nécessaire de redémarrer le processus.

Les pages web sont générées à la volée pour de nombreuses raisons, et le système de macros est la manière dont Greenstone implémente la souplesse nécessaire. On peut présenter des pages dans de nombreuses langues différentes, et on utilise un fichier de macros différent pour stocker tout le texte de l'interface dans chaque langue. Quand Greenstone affiche une page l'interpréteur de macros consulte une variable de langue et charge la page dans la langue appropriée (ce système ne va pas, malheureusement, jusqu'à traduire le contenu du document). De même, les valeurs de certaines variables d'affichage, telles que le nombre de documents trouvés par une recherche, ne sont pas connues à l'avance: elles sont interpolées dans le texte de la page à l'aide de macros.

Les fichiers de macros ont pour extension .dm. Chaque fichier définit un ou plusieurs paquetages, et chaque paquetage définit une série de macros utilisées dans un but précis et unique. À l'instar des classificateurs et des greffons, il existe une base à partir de laquelle construire des macros, appelée base.dm; ce fichier définit le contenu de base d'une page.

Les macros portent des noms qui commencent et finissent par un caractère de soulignement, et leur contenu est défini à l'aide d'accolades. Leur contenu peut consister en du texte brut, du HTML (y compris de liens vers des appliquettes (applets) Java ou du JavaScript), des noms de macros, ou toute combinaison de ces éléments. La macro suivante, extraite du fichier base.dm, définit le contenu d'une page en l'absence de toute macro de remplacement:

_content_ {<p><h2>Oops</h2>_textdefaultcontent_}

Cette page affichera «Oops» à son sommet, suivi du contenu de la macro d'erreur correspondante, _textdefaultcontent_ qui est en anglais définie comme suit: Global:textdefaultcontentThe requested page could not be found. Please use your browsers 'back' button or the above home button to return to the Greenstone Digital Library.; dans d'autres langues, elle affichera une traduction appropriée de cette phrase. En français, on obtiendra par exemple Global:textdefaultcontentLa page demandée n'a pu être trouvée. Utilisez s'il-vous-plaît le bouton «retour» de votre navigateur, ou le bouton «accueil» pour retourner à la Bibliothèque Numérique Greenstone.

Les deux macros _textdefaultcontent_ (contenu textuel par défaut) et _content_ (contenu) se trouvent dans le paquetage global car elles sont requises dans toutes les portions de l'interface utilisateur. Les macros peuvent utiliser des macros d'autres paquetages en tant que contenu, mais il faut alors qu'elles en préfixent les noms par le nom du paquetage. Exemple:

_collectionextra_ {This collection contains _about:numdocs_ documents. It was last built _about:builddate_ days ago.)

provient du fichier french.dm (macros pour le français), et elle est utilisée comme description par défaut d'une collection. Elle fait partie du paquetage intitulé global, mais les macros _numdocs_ et _builddate_ se trouvent toutes deux dans le paquetage about (à propos de…) – d'où le about qui préfixe leurs noms.

Les macros renferment souvent des conditionnelles, qui ressemblent aux conditonnelles de chaînes de formatage décrites plus haut, à ceci près que leur apparence est un peu différente. Le format de base est _If_(x,y,z), où x est une condition, y est le contenu de macro à utiliser si cette condition est vérifiée, z le contenu à utiliser dans le cas contraire. Les opérateurs de comparaison sont les mêmes que les opérateurs simples utilisés dans Perl (moins que, plus que, égale, différent de). L'exemple suivant, extrait du fichier base.dm, sert à déterminer comment afficher le sommet de la page À propos de cette collection d'une collection:

_imagecollection_ {
       _If_( "_iconcollection_ " ne "",
                 <a href = "_httppageabout_ "> 
                         <img src = "_iconcollection_ " border = 0>
                         </a>,
                 _imagecollectionv_)
}

Voilà qui peut sembler abscons. La macro _iconcollection_ vaut la chaîne vide si la collection ne dispose pas d'une icone, ou le nom de l'image dans le cas contraire. Pour paraphraser le code ci-dessus en français: s'il existe une image de collection, afficher l'en-tête de page à propos (à laquelle on se réfère par _httppageabout_) et puis cette image; sinon afficher la solution de secours _imagecollectionv_.

Les macros peuvent prendre des arguments. Voici une autre définition de la macro _imagecollection_, suivant immédiatement la définition donnée plus haut, dans le fichier base.dm:

_imagecollection_[v=1]{_imagecollectionv_}

L'argument [v=1] spécifie qu'il faut utiliser cette deuxième définition quand Greenstone fonctionne en mode texte seul. Les macros de langue fonctionnent de manière similaire – à l'exception du fichier english.dm, qui est le fichier utilisé par défaut, toutes les macros de langue spécifient leur langue en argument. Par exemple:

_textimagehome_ {Home Page}

apparaît dans le fichier de macros pour la langue anglaise, alors que la version allemande est:

_textimagehome_ [l=de] {Hauptaseite}

Les versions anglaise et allemande se trouvent dans le même paquetage, bien qu'elles soient stockées dans des fichiers séparés (les définitions de paquetages peuvent occuper plusieurs fichiers). Greenstone utilise son argument l au moment de l'exécution pour décider quelle langue afficher.

<imgcaption figure_part_of_the_aboutdm_macro_file|%!– id:714 –%Portion du fichier de macro about.dm ></imgcaption>

package about
##############################################
# about page content
###############################################
_pagetitle_ {_collectionname_}
_content_ {
<center>
_navigationbar_
</center>
_query:queryform_
<p>_iconblankbar_
<p>_textabout_
_textsubcollections_
<h3>_help:textsimplehelpheading_</h3>
_help:simplehelp_
}
_textabout_ {
<h3>_textabcol_</h3>
_Global:collectionextra_
}

Comme dernier exemple, la figure <imgref figure_part_of_the_aboutdm_macro_file> montre un extrait du fichier de macros about.dm, utilisé pour générer la page à propos de chaque collection. Elle montre la définition de trois macros, _pagetitle_ (titre de page), _content_ (contenu), et _textabout_ (texte «à propos de…»).

Les macros sont puissantes, et peuvent sembler un peu obscures. Mais avec une bonne connaissance de HTML et un peu de pratique elles deviennent une manière rapide et facile de personnaliser votre site Greenstone.

Supposons par exemple que vous souhaitiez créer une page statique qui ressemble à votre site Greenstone actuel. Vous pouvez créer un nouveau paquetage, que vous appellerez static par exemple, dans un nouveau fichier, et y redéfinir la macro _content_. Ajoutez ce nom de fichier dans GSDLHOME/etc/main.cfg, que Greenstone charge à chaque fois qu'il est invoqué. Vous accéderez à la nouvelle page en utilisant votre URL habituelle pour Greenstone et en lui ajoutant les arguments ?a=p&p=static (on obtiendra par exemple l'URL complète suivante: http://serveur/cgi-bin/library?a=p&p=static).

Pour modifier l'apparence et l'ergonomie de Greenstone vous pouvez éditer les paquetages base et style. Pour modifier la page d'accueil de Greenstone, éditez le paquetage home (ceci est décrit dans le Guide d'installation de la bibliothèque numérique Greenstone). Pour modifier la page de requêtes, éditez le fichier query.dm.

Expérimentez sans crainte avec les macros. Les modifications apparaissent instantanément, puisque les macros sont interprétées lors de l'affichage des pages. Le langage de macros est un outil puissant que vous pouvez utiliser pour vous approprier vraiment votre site Greenstone.

<tblcaption table_the_packages_directory_1|Le répertoirepackages></tblcaption>

Le répertoire packages (paquetages), dont le contenu est représenté dans la table <tblref table_the_packages_directory_1>, est l'endroit de stockage de tout le code utilisé par Greenstone mais écrit par des tiers ou d'autres équipes de recherche. Tout le logiciel distribué avec Greenstone a été publié sous la licence publique générale de GNU (GPL). Les exécutables produits par ces paquetages sont placés dans le répertoire bin de Greenstone. Chaque paquetage est stocké dans son propre répertoire. Les différents paquetages ont des fonctions très diverses, allant de l'indexation et de la compression à la conversion de documents du format Microsoft Word en HTML. Chaque paquetage dispose d'un fichier README (lisez-moi) qui fournit des informations complémentaires le concernant.