Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Éditeur XMLDB, celle pour les versions 3.x de Moodle est consultable ici : Éditeur XMLDB et celle pour Moodle 4.x est consultable là : Éditeur XMLDB.

Éditeur XMLDB

De MoodleDocs
Révision datée du 17 juin 2015 à 09:38 par Séverin Terrier (discussion | contributions) (→‎Conventions)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à :navigation, rechercher

Remarque : la traduction de cet article n'est pas terminée. N'hésitez pas à traduire tout ou partie de cette page ou à la compléter. Vous pouvez aussi utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.


Moodle1.7

Emplacement : Administration > Divers > Éditeur XMLDB


  • L'éditeur XMLDB est un outil permettant de créer les fichiers .xml qui spécifient comment Moodle doit mettre en place ses tables de base de données interne. Auparavant, les développeurs devaient créer des fichiers d'installation .sql séparés pour mysql et postgres. Maintenant, un seul fichier est nécessaire, et permet le support de plusieurs types de bases de données.
  • L'édition des tables, champs, clés ou index est ainsi grandement facilitée. Cela permet aux développeurs de se consacrer à la programmation et à l'amélioration de la plate-forme au lieu de se battre avec les fichiers XML et les erreurs dues à leur édition à la main (ils peuvent aussi à loisir consacrer le temps gagné à la bière, la danse, aux livres, à la musique...) ;-)
  • Tous les nouveaux fichiers install.xml présents dans les répertoires db de Moodle peuvent être modifiés (et c'est souhaitable) en quelques clics et raccourcis clavier. Ces fichiers comportent toutes les données utiles pour créer les objets nécessaires aux différents SGBD supportés par Moodle.
  • Remarque : afin de manier ces fichiers, le serveur web doit pouvoir accéder en écriture à tous les répertoires db où se trouvent les fichiers install.xml (ainsi qu'à ces fichiers eux-mêmes bien-sûr). Si les lien Créer ou Charger sont inactifs, cela signifie soit que vous n'avez pas créé de répertoire db, soit que le serveur ne peut y écrire.


Utilisation

  • L'éditeur XMLDB est très simple d'utilisation et ne nécessite pas un manuel entier. En jouant un peu avec, vous verrez comment il fonctionne et comment il modifie les fichiers install.xml.


  • L'éditeur est organisé de façon hiérarchique. Il vous faut d'abord charger (ou Créer) un fichier XMLDB. Ensuite vous pouvez le Modifier pour voir sa structure générale. Cette structure comporte deux types d'éléments, les tables et les statements, que l'éditeur XMLDB vous permet d''ajouter, modifier, supprimer ou déplacer aisément. De même, pour la création de tables, un petit mais utile outil de reverse-ingineering a été créé (pour MySQL seulement). Il permet de modifier les tables de la base de données dans l'éditeur XMLDB.
  • Durant la modification des tables, vous verrez leur champs, leurs clés et index que vous pourrez manipuler simplement. Attention toutefois : certains champs, en cours d'utilisation, ne sont pas modifiables. Ceci permet de vous avertir qu'ils peuvent, par exemple, faire partir d'une clé ou d'un index.
  • Dans les champs modifiables, vous pouvez préciser leur nom, leur type, leur longueur, le nombre de décimales, leur valeur par défaut, etc... Il en est de même pour les clés et les index.


  • Whilst editing statements, you must think about them like "collections of sentences". Once you select the type (only inserts are allowed for now) and table you are interested in, you'll be able to introduce the exact values easily, being able to duplicate them easily to gain some speed if you have a lot of sentences in your development. Sentences can be edited and deleted easily too.
  • One interesting feature is that all the XMLDB editor pages allow you to enter a comment about the item being modified (table, index, key, field, statement). Use it as you wish, sure that it helps other developers to understand a bit more about the DB model.

Once you have created the install.xml file, you still need to manually create an upgrade.php file in your module's db folder in order to add the tables to your database. The upgrade.php file should start off looking something like this:

<?php

function xmldb_realtimequiz_upgrade($oldversion) {
    global $CFG;

    $result = true;

// Insert PHP code from XMLDB Editor here

    return $result;
}
?>

To get the code for the '// Insert PHP code here' bit, open the XMLDB Editor and load the relevant install.xml file. Choose the 'View PHP' option and then copy and paste the generated code.

Conventions

En plus des Database Structures guidelines, il existe quelques conventions supplémentaires à suivre :

  1. A propos des noms :
    1. Tous les noms seront en minuscule (tables, indexes, clés et champs).
    2. Les noms des tables et des champs doivent utiliser uniquement les caractères a-z, 0-9 et _. Maximum 28 caractères.
    3. Key and index names under the XMLDB Files must be formed by concatenating the name of the fields present in the key/index with the '"-" (minus) character.
    4. Primary key always must be named "primary" (this is one exception to the previous convention).
    5. Il est fortement recommandé d'éviter complètement les mots réservés. We know we have some of them now but they should be completely out for next releases.
  2. A propos des NULLS
    1. Avoid to create all the fields as NOT NULL with the silly default value '' (empty string). The underlying code used to create tables will handle it properly but the XMLDB structure must be REAL. Read more in the [[:en:XMLDB Problems#NOT NULL fields using a DEFAULT '' clause|Problems Page]].
  3. A propos des FOREIGN KEYS
    1. Under the tables of every XMLDB file, you must define the existing Foreign Keys (FK) properly. This will allow everybody to know a bit better the structure, allow to evolve to a better constrained system in the future and will provide the underlying code with the needed info to create the proper indexes.
    2. Note that, if you define any field combination as FK you won't have to create any index on that fields, the code will do it automatically!
    3. Respecter la Convention 1.3
  4. A propos des UNIQUE KEYS
    1. Déclarer les champs comme UNIQUE KEY (UK) seulement s'ils vont être utilisés comme cible pour une clé étrangère. Sinon, créez des indexes uniques.
    2. Respecter la Convention 1.3

Voir aussi