suivant: La Sofia monter: Ex Lude précédent: Ex Lude
Clyo est le gestionnaire d'informatyons pour Ys et ses citoyens. Clyo est le nouveau de D@ndale.
Clyo est un ensemble de scripts écrits en PHP qui permettent de gérer certains aspects de la vie yssoise. Le programme est maintenu par un "groupe" de joueurs-programmateurs, qui se réunyssent sur une lyste de diffusion spécialysée dandale50.1 .
Le fonctionnement de Clyo repose sur deux piliers : le pilier des concepts gérés et le pilier des méthodes.
1. 1. le pilier des méthodes
Le pilier des méthodes comprend plusieurs classes :
1. 1. 1. la classe "mysqldb.php"
Cette classe gère un objet représentant une connexion à la base mysql.
Cet objet comprend trois attributs : connect, id et base. * connect : prend la valeur 1 s'il y a une connexion active ; * id : identifiant de la connexion (si plusieurs connexions actives, ce qui n'arrive jamais sous Clyo) * base : base à laquelle on est connectée.
Il comprend plusieurs fonctions, dont : * mysqldb() : fonction constructeur, qui établit la connexion. Créer un objet mysql suppose donc automatiquement la connexion à la base. Les paramètres de connexion peuvent être passés à la fonction, mais c'est facultatif. Par convention, il y a un objet mysql ouvert, et il s'appelle $m.
Utilisation : include("../Classes/mysqldb.php"); $m = mysqldb();
* unik($query) : si $query est une requête qui doit ne retourner qu'un seul résultat, alors unik($query) retourne ce résultat, sous forme directement exploitable. En pratique, une requête renvoie normalement un tableau, et il faut extraire de ce tableau la ou les informations utiles. Ici, par principe, il n'y en a qu'une, et la fonction s'occupe de l'extraire.
Utilisation (exemple : récupérer le nom du personnage qui porte le numéro 5) : $nom = $m->unik("SELECT nom FROM personne WHERE num=5");
* send($query) : envoie la requête $query.
Utilisation correcte : $query = "SELECT * FROM personne"; $q = $m->send($query);
* displaytable($query, $leg, $mod, $sup) : affiche une table avec le contenu de la requête. Chaque colonne porte en titre le nom du champ de la table, si $leg est différent de 0. $mod et $sup sont facultatifs également. Ils permettent d'afficher une case spéciale, avec un lien, respectivement pour modifier la ligne concernée ou la supprimer. $mod et $sup doivent contenir le nom du fichier. Cela produit un lien du type : Modifier ou Supprimer l est le quantième de l'enregistrement dans la liste.
Exemple d'utilisation, pour afficher tous les champs de la table personne. $q = "SELECT * FROM personne"; $m->displaytable($q, 1, "modperso.php", "deleteperso.php");
Si vous n'y comprenez rien, mettez juste le nom du fichier, car voilà la fonction de traitement :
* formofmodif($f, $query, $l). Cette fonction crée un formulaire, affiche les différents champs de la requête et de la ligne concernée, pour permettre de les modifier. Automatiquement. Attention, les formulaires sont très simplifiés, pour le moment, et ne détectent pas le type de donnée à entrer, ni n'opèrent de corrections. Le formulaire renvoie sur le fichier $f.
Utilisation if ($form == "ok") //traitement de l'info else $m->formofmodif($f, $query, $l);
* getline($table, $num). Renvoie la ligne où le champs num est égal à $num (par convention, sur Clyo, TOUTES les tables ont une clef appelée num), de la table $table.
Utilisation $row = $m->getline("personne", "5");
* deleteline($table, $num). Efface la ligne où le champs num est égal à $num.
Utilisation $m->deleteline("personne", "18");
* setdata($table, $data, $value, $num). Modifie le champ $data en y inscrivant la valeur $value, à la ligne $num de la table $table.
Utilisation $m->setdata("personne", "nom", "Paxatagore," 5);
* mdate($date) : traduit une date au format mysql en format "humain" (français : jour / mois / année).
Utilisation $m->mdate("2002-02-05");
* close() : ferme la connexion active.
1. 1. 2. la classe "formulaire.php"
Cette classe permet de gérer les formulaires. Le formulaire qui est ainsi produit voit son affichage normalisé, et inscrit dans un tableau à deux colonnes, d'un côté le nom des champs à remplir, de l'autre les champs proprement dit.
Les objets formulaires portent par convention le nom : $f.
Les fonctions utiles sont les suivantes :
* formulaire ($nom, $action, $centred, $width). Il s'agit de la classe constructeur. Elle instancie le formulaire, mais ne l'affiche pas. Il s'agit uniquement de définir le nom du formulaire (qui sera affiché au sommet de celui-ci), le fichier qui est appelé ($action), si le formulaire est centré ($centred = 1) ou non ($centred = 0), et quelle est sa largeur ($width, en pourcentage).
* open() : affiche le « haut du formulaire » : création du , et de la table qui encadre l'affichage du formulaire.
* close($param). Affiche le « bas du formulaire » : boutons d'envoi, fin de la table qui encadre l'affichage du formulaire. Param est égal à 2 par défaut, et affiche le bouton envoyer et le bouton effacer. Si param est égal à 1, cela n'affiche que le bouton envoyer. Si param est égal à 0, cela n'affiche aucun bouton.
* add_submenu($text) : affiche un « sous-menu » dans le formulaire. Le titre du sous menu, $text, est affiché en gras, sur les deux colonnes.
* add_explication($text) : affiche une ligne d'explication. L'explication, $text, est affichée sur les deux colonnes.
* add_text($texte, $nom, $maxlength=70, $value="", $posttext="") : ajoute un ligne au tableau avec un champ de type TEXT. Sur la première colonne, affiche $texte en gras. $nom est le nom du champ du formulaire. $maxlength, la longueur maximale des données. $value est la valeur type. $posttext est un texte à afficher après le champ proprement dit.
Exemple d'utilisation $f = new formulaire(« Test », « test.php ») ; $f->open(); $f->add_submenu(&8220;Première partie&8221;); $f->add_text(« Votre nom », « nom », 50) ; $f->add_text(« Votre âge », « age », 3, « », « ans ») ; $f->close() ;
* add_password($texte, $nom, $maxlength=70, $value=""). Idem, mais affiche un champ de type &8220;password&8221;.
* add_text_area($texte, $nom, $contenu="", $cols=40, $rows=8, $editor_url = "../htmlarea/"). Idem, mais affiche un champs de type &8220;text_aera&8221;. $cols et $row sont la longueur et la hauteur du champs. Par défaut, l'éditeur HTML de Clyo est un script en javascript qui permet de faire du WYSIWYG.
* add_text_areaf($texte, $nom, $file, $cols=40, $rows=8). Idem, mais affiche le contenu du fichier $file dans le champs « text_area ».
* add_secret($varname, $variable). Affiche un champs de type Hidden, avec $varname comme nom de la variable cachée, et $variable comme valeur de la variable cachée.
* add_element($texte1, $texte2). Affiche $texte1 en gras dans la première colonne et $texte2 dans la seconde colonne. $texte2 peut être une simple information, ou un champs de formulaire sophistiqué, non pris en charge.
* add_choice($texte, $query, $variable, $valuereturn, $valuedisplay, $valuetest=0). Affiche une liste de choix. $texte est affiché en gras dans la première colonne. Un champ select est affiché dans la seconde colonne, avec $variable comme nom de variable. La requête $query est lancée, et le résultat détermine l'affichage du menu déroulant : $valuedisplay est le nom de la variable affichée, $valuereturn est le nom de la variable retournée. Si $valuetest est définie, ce sera la valeur d'affichage par défaut du menu déroulant.
Exemple d'utilisation : afficher la liste des personnes, mais renvoyer le numéro de la personne $f->add_choice(« Personne », « SELECT * FROM personne », « personne », « num », « nom », 5) ;
* add_date($texte, $valeur = 0). Permet d'afficher une date. $valeur contient la date à afficher.
Nota : une fois défini, le formulaire est affiché, ligne après ligne.
Etat de la classe : cette classe est une classe assez ancienne, qui comprend d'ailleurs quelques fonctions non documentées ici, utiles simplement pour Clyo. La classe devrait être prochainement considérablement remaniée, sans que l'utilisation ne soit changée.
1.1.3. La classe « fichier.php »
Elle permet de gérer le chargement et l'écriture de fichiers de donnée.
1.1.4. La classe « mail.php »
Elle permet de gérer l'envoi de mail. Les fonctions sont les suivantes :
* save_mail($exp, $des, $sub, $con). Envoie un mail de $exp à $des, qui sont tous deux le numéro d'une personne dans la table personne. Le sujet du mail est $sub, le contenu $con.
* normalmail($adrexp, $adrdes, $sujet, $contenu). Envoie un mail à l'adresse mail $adrdes, depuis l'adresse mail $adrexp, avec $sujet comme sujet et $contenu comme contenu.
Les mails sont envoyés au format HTML.
1.1.5. Le fichier « skin2.php »
Il contient deux classes, utiles à l'affichage de données : - box : affiche une « boîte » en HTML, toute simple. - boxtable : affiche un tableau en HTML, avec une légende.
1.1.6. La classe "dandale22.php"
Cette classe doit être chargée en mémoire par chaque fichier.
Elle instancie automatiquement une connexion à mysql ($m).
Elle définit la variable globale $dandalemonnaie : monnaie de la nation utilisatrice.
Elle fournit les fonctions suivantes :
* secure() : vérifie qu'une personne est bien connectée. Si ce n'est pas le cas, le script est arrêté et l'utilisateur est renvoyé vers le formulaire d'identification. S'il y a une personne qui est connectée, ses données sont chargées en mémoire dans l'objet, de type personne, $p.
* menu() : affiche le menu principal de l'application.
* close() : termine l'affichage d'une page (en fermant par exemple un tableau ouvert par menu, en affichant des messages divers...) 1.2. Le pilier des concepts gérés Par « concepts gérés », on désigne en fait les informations gérées, stockées et modifiées par Clyo, par opposition aux méthodes, qui ne gèrent que la façon dont l'affichage se fait, la connexion à mysql est opérée...
Il y a un « modèle clyo », qui repose sur les principes suivants :
1 type d'objet = 1 table = 1 classe = 1 fichier de classe
1.2.1. La table
Chaque table doit comprendre nécessairement une clé, appelée num (en minuscule), de type numérique automatique.
Les autres champs sont libres.
1.2.2. La classe La classe doit hériter de la classe dobjet (qui se trouve dans le fichier dobjet.php), avec la commande
Class nomdeclasse extends dobjet
L'héritage de dobjet fournit toute une série d'attributs et de fonctions, qui n'ont pas besoin d'être repris (c'est même le principe de l'héritage).
Comme attributs : * num : l'attribut du champs clé * table : le nom de la table * arr : un tableau, destiné à contenir les informations sur la classe et le type des données * iq : un identifiant
Comme fonctions : * get($n) : charge en mémoire la ligne $n de la table. * delete() : efface de la table la ligne $n. * select($string) : sélectionne toute la table. Si $string est définie, c'est un complément de la requête de sélection, de la forme « WHERE condition ORDER BY ordre », par exemple. Le résultat est stocké dans $this->iq. * lenen() : après l'exécution de select(), indique le nombre de ligne retournée. * next() : charge en mémoire la ligne suivante. Ces fonctions n'ont pas besoin d'être modifiées ou surchargées.
Elle fournit également une fonctions qui doit être définies dans la classe-fille : - getrow($row) : $row est le résultat renvoyé par get($n). En traitant l'information contenue dans $row, il remplit l'objet.
Elle fournit enfin des fonctions qui gagnent à être définies dans la classe-fille : - display - modify
1.2.3. Schéma de la classe fille
Typiquement, une classe fille s'écrit ainsi :
Classe nomdelaclasse extends dobjet //ici, la liste des attributs de la fonction //qui correspondent à la liste des champs de la table mysql correspondant //exemple : var $nom ; var $prenom ; var $adresse ;
fonction nomdelaclasse() //fonction constructeur $this->table = « nomdelatable » ;
function getrow($row) //cette opération est indispensable : //les attributs doivent être rangés dans le même ordre que dans la table mysql list($this->num, $this->nom, $this->prenom, $this->adresse) = $row ; //cette opération est facultative, mais bien utile : //il s'agit d'enlever les '/' que met mysql dans les chaînes de caractère //il faut donc l'appliquer à tous les attributs qui sont de ce type $this->prenom = stripslashes($this->prenom); //enfin, une ligne également indispensable : return 1 ;
//autres fonctions
Idéalement, les autres fonctions devraient être notamment : - set() : pour créer une nouvelle ligne dans la table mysql (définir une nouvelle instance de l'objet) ; - setnomdel'attributs() : pour changer le nom de l'attribut ; - display() : pour afficher les informations de l'objet ; - modifiynomdel'attribut() : pour modifier le nom de l'attribut.
1.2.4. Utilisation de la classe fille
La classe fille définit un nouveau concept, qui est pris en charge par l'application.
Prenons par exemple la classe dpersonne, qui définit le concept de « personne ». Il faut d'abord charger la classe :
Include(« ../Classes/dpersonne.php ») ;
(à noter qu'en pratique cette classe est chargée par dandale22.php, il est donc inutile de l'ajouter manuellement).
Ensuite, il faut instancier un objet :
$p = new personne ;
Après, tout dépend de ce qu'on veut faire. On peut d'abord vouloir que $p corresponde à une personne précise, par exemple la personne numéro 8. En ce cas, on fait :
$p->get(8) ;
Et aussitôt, on dispose des attributs de la personne 8, qu'on peut utiliser facilement, par exemple :
Echo $p->nom ; Echo $p->prenom ;
On peut aussi utiliser certaines fonctions, qui seront appliquées à la personne 8 :
$p->setnom(« Royal air force ») ;
changera le nom de la personne 8 en « Royal air force ».
On peut également souhaiter travailler sur plusieurs personnes, successivement, par exemple pour afficher une liste de personnes. En ce cas, on peut faire :
$p->select(« WHERE num < 10 ») ;
(pour sélectionner les personnes de 0 à 10)
$n = $p->lenen() ;
(pour connaître le nom de personne que l'on a sélectionné).
While ($n->next()) Echo $p->nom ; Echo $p->prenom ;
(on fait défiler les personnes une par une, grâce à la boucle while et à la fonction next(), et on affiche pour chacune leur nom et leur prénom).
Rappel sur Dandale. A l'origine, Dandale était un projet global pour repenser le micromonde selon des bases radicalement nouvelles. Très vite, il est apparu qu'il fallait un système de gestion d'informations pour ce nouveau système et c'est ce système qui a été développé. Le reste du projet a été totalement abandonné.
Dandale 1 Cette version a été développée sous la direction de Matthieu Duclos par Anne Etien, François Guerry et Matthieu Duclos. Elle gérait les joueurs et les personnages, les comptes bancaires, les immeubles, la presse, les procès, les transactions internationales, ... la programmatyon était encore décentralisée et il n'y avait pas de classes.
Dandale 1 a été utilisée par Nautia, le Krassland et surtout par les pays de Pseudopolis.
Progressivement, Dandale 1 a été repensé et réécrit sous forme de classes.
Dandale 2 Entière réécriture du code, sous forme de classe, Dandale 2 a été écrit pour Pseudopolis. L'apparence graphique était radicalement différente également.
Dandale 2.1 Sans réécriture du Code, Dandale 2.1 se signalait par une factorisation plus grande, et surtout une nouvelle apparence graphique.
Dandale 2.2, devenue Clyo La factorisatyon est fortement poussée, avec la créatyon de dobjet.php, et le code est progressivement adapté au php4. Dandale 2.2 n'étant plus utilisé que par Ys, et malgré quelques tentatives d'adaptatyon au Zollernberg, elle est renommée en Clyo. La charte graphique est modifiée.
Pour la première fois depuis Dandale 1, d'autres programmateurs ajoutent des fonctions : Xavier et Nicolas.
Le système est fréquemment modifié. Il est maintenu sur dandale@yahoogroupes.fr
Projets- gptc : générateur de programmes de type Clyo. Ce projet est destiné à mettre en place un générateur automatique de programmes afin de simplifier la programmation, voire le portage de Clyo sur d'autres pays. Dandale 3 pourrait être entièrement généré par le gpct.
- dandale 2.3 : les progrès envisagés sur le fond du système sont une meilleure sécurisation de la connexion, un meilleur contrôle des transactions (notamment des transactions non passées), une réorganisation des tables, une administration plus interactive (avec échange de mails systématiques). Le code devrait être d'avantage factorisé. La gestion des communautés, après avoir considérablement fluctué, devrait enfin être finalisée selon un modèle cohérent et fiable. Les classes devraient être réécrites selon un modèle type. Des méthodes générales de programmation devraient être dégagées et décrites de façon systématique.
Sur une idée de Matthieu Duclos, avec de nombreuses améliorations par Nykolaos d'Ophiccius. La création d'un générateur a amené un degré supérieur d'abstraction, et la mise en place de nouveautés, tant du côté des méthodes que du côté des concepts.
2.1. Les améliorations mineures
2.1.1. La classe formulaire
La classe formulaire devrait être modifiée de plusieurs manières.
Tout d'abord, il faudrait rajouter des « vérificateurs » de contenu, en javascript, qui vérifient que le contenu du formulaire est bien le bon.
Ensuite, il serait mieux que l'objet formulaire soit décrit, d'une part (par les différentes fonctions add), et affiche de l'autre (par la fonction close()).
Il serait intéressant de gérer les cases à cocher, les cases radio, de permettre des boutons plus personnalisés (notamment des images), et de permettre une légende par bulle.
Par ailleurs, il serait bon que chaque classe détermine l'affichage qui est le sien en cas de liste déroulante. Ainsi, lorsqu'il s'agirait de faire dérouler la liste des comptes bancaires, la liste des personnes ou encore la liste des habitations, le résultat serait différent, et produit par une fonction listederoulante() de chaque classe. Il faudrait vérifier la présence de cette fonction.
2.1.2. la classe mail
Le nom des fonctions pourrait être rendu plus intelligible. - envoiemail($exp, $des, $sub, $con) : envoie d'un mail de la personne numérotée $exp à la personne numérotée $des. - adminmail($message, $titre, $droit, $cte) : envoie d'un mail à tous les administrateurs titulaire du droit $droit de la communauté $cte. - normalmail($adrexp, $adrdes, $sujet, $contenu) : envoie un mail de $adrexp à $adrdes.
2.1.3. la gestion des empilements de communauté et des droits d'administration
Dandale a géré avec plus ou moins de bonheur les « empilement de communauté », sans qu'il existe un modèle clair de cet empilement, et de ses conséquences en termes de droit d'administration, qui, eux même, sont gérés de façon assez peu efficaces.
Chaque communauté dispose des attributs suivants : - un nom ; - une « personne support », c'est-à-dire la personne physique ou morale qui représente ou dirige la société ; - une communauté mère (0, sinon). - un lien vers la liste de droits associés. Cette liste de droits associés est en fait une table distincte, avec des couples droit-communauté.
Chaque droit dispose des attributs suivants : - un nom ; - une description ; - un numéro ;
Les personnes sont propriétaires de droits. Cela est représenté par une table distincte, avec des couples droit-personne.
La classe communauté comprend une fonction qui permet de savoir si une communauté a bien un droit donné. La classe droit comprend une fonction qui permet de savoir si une communauté ou si une personne a bien le droit considéré.
2.1.4. la poubelle intelligente
Le mécanisme de poubelle intelligente repose sur deux éléments :
1) chaque classe se voit ajouter un champ spécial, « supprimé ». Par défaut, cette variable est à 0, elle est à 1 lorsque l'objet a été supprimé. Les requêtes d'affichage impliquent donc nécessairement l'ajout d'une clause « WHERE supprime=0 » ; Régulièrement, la table doit être sauvegardée, puis un script spécial appelé qui efface toutes les lignes de toutes les tables où supprime = 1.
2) la tenue à jour des liens entre classe (cf. 2.3.2.), qui permet de remonter toutes les occurrences d'une table et de voir ce qui se passe. 2.2. la connaissance de soi 2.2.1. Connaissance par les entités C'est une grande nouveauté introduite par le concept même du générateur (et due à Nykolaos d'Ophiccius) : chaque entité du programme doit avoir une « connaissance d'elle-même ». Cela suppose notamment la définition des concepts suivants :
* les « groupes » : c'est un ensemble de scripts et de classes qui gèrent un aspect du jeu (le cadastre, les biens, les personnes...). Chaque groupe dispose de deux dossiers : un dossier avec les scripts accessibles à tous, et un dossier des scripts d'administration (réservés aux seuls administrateurs). Le générateur doit tenir à jour la liste des groupes, par une table mysql.
* les « scripts » : chaque script doit être répertorié, avec le fichier, le groupe d'appartenance, le rôle du script... Cela permet de tenir à jour le menu principal de l'application. De même, chaque script doit connaître son propre fonctionnement pour pouvoir être modifié simplement par le générateur. Le générateur doit tenir à jour la liste des scripts, par une table mysql. Au sein de chaque script, il doit y avoir les variables suivantes : - $s_group : numéro du groupe ; - $s_nom : nom du fichier - $s_description : description de l'utilité du script.
* les « classes » : également, chaque classe doit être rattachée à un groupe et répertoriée. De même, chaque classe doit connaître ses attributs et ses fonctions. Le générateur doit tenir à jour la liste des classes, par une table mysql. Chaque classe contient comme attribut un tableau qui décrit ses attributs. Le tableau des attributs ($arr) est un tableau contenant d'abord le nombre d'attributs, puis autant de tableau que d'attributs. Pour chaque attribut, un tableau précise : - le nom de l'attribut ; - sa description simplifiée (qui sera affichée, par exemple dans une légende) ; - un numéro correspondant à son type de donnée (numérique, chaîne, texte, date...) - sa longueur.
Exemple $this->attributs = array(8, array("proprio", "Propriétaire", 2, 11), array("nom", "Nom de la Compagnie", 1, 250), array("poispech", "Poissons péchés", 2, 11), array("poissech", "Poissons séchés", 2, 11), array("image", "Image", 9, 250), array("site", "Site internet", 6, 250), array("asech", "Poyssons à sécher", 2, 11), array("vsech", "Poyssons séchés à vendre", 2, 11)) ;
De même, chaque classe doit se doter un tableau identique, sur ses fonctions.
L'intérêt de la « connaissance de soi » est que cela permet de modifier facilement et automatiquement l'application.
2.2.6. Log
Afin de contrôler les bugs et de mieux saisir le fonctionnement de Clyo, il est instauré un log quotidien, selon le système suivant :
Un fichier « log » gère les logs, en fournissant notamment les mécanismes et de bases et une fonction générique makelog(). Cette fonction, qui sera appelée par chaque fonction de Clyo, inscrira ainsi les opérations effectuées par les utilisateurs. En conséquence, lors de la création d'une classe, il faut rajouter les appels à maklog().
Makealog est ainsi définie :
Makelog(« texte », utilisateur) : ajoute une ligne au fichier log du jour, avec le texte concerné et le nom de l'utilisateur.
Lors de l'appel à Makealog, le script vérifie qu'il existe bien un fichier log du jour, le cas échéant en créée un, inscrit la ligne de log dans le fichier et ferme le fichier. Le log de la veille est envoyé tous les jours aux admins. NB : une fonction spéciale, makeaglog() fonctionne de la même façon, mais tient un log mensuel : les modifications du modèles, par le générateur. 2.3. Le générateur 2.3.1. Identité du générateur et du programme Le générateur est compris et analyse comme une partie intégrante du programme. Il n'est pas distinct du programme. Chaque programme généré par Dandale 3 comprend donc son propre générateur et donc la faculté d'être modifié simplement par lui-même. Le dossier du générateur est /generateur.
Il est simplement recommandé d'avoir deux versions du programme : - une version sur un ordinateur personnel, avec le dossier générateur ; - une version sur le serveur Internet, sans le dossier générateur.
Toutefois, il est possible de sécuriser le générateur sur le serveur Internet, pour en réserver l'accès aux seuls administrateurs.
2.3.2. Fonctionnement du générateur
Au départ, le programme est fourni avec les éléments suivants : - les classes nécessaires au fonctionnement de l'application : dandale3, box, boxtable, mail, dobjet, formulaire... - les scripts du générateur.
L'utilisateur doit alors définir pas à pas l'application telle qu'il l'a désire.
Il doit définir les groupes, puis, au sein des groupes, les classes, puis les scripts. Cela permet de créer progressivement une application.
Lors de la création des classes, l'utilisateur définit en premier lieu les différents attributs des classes. Il peut notamment indiquer qu'un attribut est en fait un lien vers une autre classe, existante ou à créer.
La création et les modifications de script font l'objet d'un versioning, inscrit dans la classe sous forme de variables.
2.3.3. Types de scripts
Il existe plusieurs types de scripts, pris en charge par le générateur.
* le script de connexions. La création d'un script de connexion apparaît comme un préalable indispensable dès lors qu'on veut réserver la connexion à certaines personnes. L'existence d'un script de connexion peut ensuite être activée ou désactivée pour les scripts pris isolément. Il faut indiquer au générateur dans quelle table sont pris les logins et mots de passe. Cela suppose d'avoir défini une classe utilisateur (ou personne, ou joueurs...). Par défaut, les scripts de connexion se trouvent dans la racine et dans le dossier /Main.
* les scripts de création, d'affichage, de modification et de suppression de données. Ces scripts affichent respectivement : - un formulaire pour créer un nouvel objet (exemple : un nouveau joueur) ; - des listes de données, à partir d'une requête (exemple : la liste des joueurs), avec des liens de modification ou de suppression, au besoin ; - des formulaires pour modifier les données ; - la suppression de la donnée. Ces scripts ne permettent donc aucun traitement informatisé des données, sauf modification par l'utilisateur à l'aide d'un formulaire.
* Le mécanisme de transaction. Il s'agit de faire "coulisser" certaines données d'une partie de la base à un autre. L'exemple typique, c'est la transaction bancaire. On peut dire, en gros, qu'une transaction se fait d'une ligne à une ligne dans une même table.
* Le mécanisme de contrat. On distingue des mécanismes de contrat simple, des mécanismes de contrat avec double approbation. Le contrat est simple lorsqu'une personne émet une offre et que le contrat est accepté dès lors que toute personne (ou la personne désignée par l'offre) a accepté l'offre. Le contrat est avec double approbation lorsqu'une personne émet une offre, et que d'autres personnes (ou une autre personne désignée) émet une proposition d'acceptation, et que le contrat n'est passé qu'après validation de la proposition d'acceptation par l'émetteur de l'offre.
* Les mécanismes de modification de l'information. Plus génériquement, il s'agit de transformation des informations, par des algorithmes, sur la base, généralement, d'autres informations. A l'heure actuelle, il apparaît difficile d'en faire une théorie générale.
2.3.4. Options de scripts
- vérifier (ou non) si une personne est connectée avant le lancement du script ; - vérifier (ou non) si une personne dispose d'un droit particulier. - ajout d'un texte avant l'affichage d'un formulaire.
2.3.5. Méthode de modification des scripts
La méthode est due à Nykolaos d'Ophiccius et repose, lors de la création de tout script (ou de toute classe), de l'ajout, à la fin de chaque moment clé de balises spécifiques. Cela permet après facilement de rechercher ces balises et de les remplacer par un texte, comprenant la modification plus de nouveau les balises (pour des modifications ultérieures).
Sérényssime Empire d'Ys