Langages et normes Voici quelques règles sur le langage, la syntaxe et les normes de développement en vigueur pour le projet GSB

Transcription

1 Langages et normes Voici quelques règles sur le langage, la syntaxe et les normes de développement en vigueur pour le projet GSB Normes Copyright : Tout fichier PHP doit avoir un en-tête selon le masque suivant : <?php /*Copyright(C YYY John Doe < @ .com> * *Licence information */?> Quand vous éditez un fichier existant du projet, ajouter une ligne Copyright sous celles existantes. Normes PHP : GSB est écrit en PHP et supporte toute version PHP supérieure à la (requires functions like DataTimeZone.getOffset). Les fichiers doivent tous comporter l'extension.php. L'appel aux variables super-globales PHP doit passer par les opérateurs dédiés $_COOKIES, $_SERVER, $_ENV pour récupérer les contenus $_GET ou $_POST. Les autres opérateurs($http_server_get...) ayant été passés en deprecated au sein de PHP, ne doivent plus être utilisés. Ainsi le code doit fonctionner, y compris quand l'option register_long_array est à off. De plus, le code doit fonctionner quand l'option PHP register_globals est à OFF (recommandé par PHP aussi bien que quand l'option register_globals à est ON (par défaut sur de nombreuses installations). Pas d'utilisation de la variable PHP_SELF. Utiliser à la place $_SERVER[«PHP_SELF»]. Quand plusieurs variables doivent être initialisées avec la même valeur, il faut utiliser plusieurs lignes : $var1=1 : $var2=1 ; $var3=1 ; plutôt que : $var1=$var2=$var3=1 ; qui est moins performant. Les chaînes doivent être encadrées de simple quote et les variables sorties de la chaîne : Print 'Mon texte affiche ma'. $variable.'!' ; Les commentaires doivent suivre la syntaxe C, ie un double antislash pour un commentaire d'une ligne et utilisation d'un slash-étoile pour ouvrir un bloc de plusieurs lignes.

2 /*Bloc de commentaires * */ $monprojet=new(monobjet($db) ; $result=$monobjet->fetch($dbobject) ; for ($i=1, $i<2 ;$i++) { //Commentaire sur une ligne print $i ; } Les fonctions doivent retourner une valeur strictement supérieure à 0 en cas de succès, et un nombre inférieur à 0 en cas d'erreur. Pas de code mot (non utilisé) dans le code principal de GSB(le code utilisé uniquement par un module externe doit être inclus dans le module externe). Utiliser «include_once» pour l'inclusion de tout fichier contenant des définitions de fonction ou de classe(donc fichiers *.class php et *.lib php) et utiliser «include» pour toute inclusion de fichier de type template ou contenant un mixte de HTML et PHP(donc fichiers *.inc php et *.tpl php). Normes SQL : Structure des tables et champs : Toutes les tables sont préfixées pour éviter les conflits de nommage. Aujourd'hui le préfixe est modifiable au moment de l'installation. Lorsque vous créez une table, il est recommandé de prendre les mêmes convention de nommage de tables que les autres tables GSB. Clé primaire : La clé primaire d'une table s'appelle id. Il y a quelques tables qui échappent à cette règle actuellement pour des raisons historiques. Une évolution pourra être étudiée pour une prochaine version. Clé étrangère : Le nom d'une clé étrangère commence par le préfixe fk_suivi du nom de la table liée(requis pour éviter les doublons globales à la base, problématique sous certains SGBD comme postgresql) puis du champ lié (pour permettre plusieurs clés étrangères différentes sur une même table) Clé alternative : Parfois, il n'y a pas que la clé étrangère qui doit être unique. On peut donc ajouter aussi un index clé alternative unique. Un tel index est nommé par un nom qui commence par le préfixe uk suivi du nom de la table d'un underscore(requis pour éviter les doublons d'index globales à la base problématiques sous certains SGBD comme postgresql) puis un suffixe qui

3 caractérise la clé(pour permettre plusieurs index uniques sur une même table. Index performance : Certains champs sont souvent utilisés comme critère de recherche, de tri ou de jointure. Il convient dans ce cas, d y mettre un index de performance. De tels indexes seront nommés avec un préfixe idx_ puis le nom de la table et le nom du champ sur lequel porte l index. Format de fichier DDL: Les fichiers qui contiennent la définition de la structure de la base(ddl) doivent être au nombre de 2 par table. Chaque table est définie dans son propre fichier dont le nom est llx_matable.sql. On mettra un commentaire à côté de chaque champ pour en expliquer la signification. Les clés étrangères et index de performance ou autres contraintes d unicité sont définies dans un fichier séparé dont le nom est llx_matable.key.sql. Ces fichiers sont placés dans le répertoire install/mysql/tables pour les fichiers standards ou monmodule/tables pour les tables amenées par un module. Exemple: fichier table llx_matable.sql: ==================================================== Copyright (C) 2008 Author < @author.com> This program is free softvare ; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation ; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see < ====================================================== CREATE TABLE llx_matable ( rowid integer AUTO_INCREMENT PRIMARY KEY, field_one integer, field_two integer NOT NULL, fk_field integer, field_date datetime, tms timestamp )ENGINE=innodb;

4 Exemple : fichier clés/index llx_matable,key,sql ====================================================================== ===== Copyright (C) 2008 Author < @author.com> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see < ====================================================================== ===== ALTER TABLE llx_matable ADD UNIQUE uk_matable_field(field_one, field_two); ALTER TABLE llx_matable ADD CONSTRAINT fk_matable_fk_field FOREIGN KEY (fk_field) REFERENCES llx_matablepere (rowid); Règles de codage SQL : -Utilisation des alias/nommage des champs Dans le cas des select, on pourra utiliser les alias pour simplifier l'écriture des requêtes : SELECT chp1, chpxxx2 As chp2 FROM table1 As t1, table2 As t2 WHERE t1,chpx=t2.chpy ; Toutefois, il ne faut pas utiliser cet alias sur des requêtes update car non compatible avec mysql3.1 -Les SELECT* sont interdits! Chaque SELECT doit spécifier la liste complète des champs à récupérer. Cela permet d'éviter les confusions. Exemple : SELECT field_a, field_b, field_c FROM table_1 WHERE field_d= «$id» ; -Dans les requêtes SQL, on quote les champs mais pas les numériques qui contiennent des montants destinés à être stockés dans des champs de type double ou réel. Les quotes sur les numériques de type float provoquent parfois

5 un stockage d'une valeur différente. Par exemple, 412,62 dans le INSERT sera en fait stocké avec la valeur 412, en base(suite à des conversions chaines-numériques implicites) si le champ est de type double(24,8). Et seul PHP voit 412, Les autres outils verront 412,62 donnant l'impression qu'il n'y a pas de problème. Et c'est le PHP qui a raison, il y a un problème en base. En supprimant les quotes sur les numériques, cela va mieux. Exemple : Bon : INSERT INTO table_1 (field_txt, field_num) VALUES('txt', ) Mauvais :INSERT INTO table_1 (field_txt, field_num) VALUES('txt', '412.62') Remarque : le problème des float est général et pas seulement sur les accès base, il est présent dans tous les langages quand on travaille sur des nombres réels, aussi ils doivent être, dès que affectés, nettoyés par la fonction price2num avec le 2eme paramètre renseigné à «MU». -Les fonctions NOW ou SYSDATE sont interdites au sein des ordres SQL. S'il faut la date du moment dans un champ, la valeur doit venir de PHP et non du moteur de base de données. Ceci afin d'avoir une meilleure portabilité du code mais surtout d'avoir une gestion correcte des TimeZone. Règles de migration de base : Les scripts de migration de structure sont les fichiers de type install/mysql/migration/monfichier.sql. Dans un fichier de migration n vers n+1, on ne détruit pas une table(drop TABLE) qui n'est plus utilisée en n+1 que lors de la migration de la version n+1 vers n+2. Ceci afin de toujours conserver les tables deprecated le temps d'une version pour réparer une situation en cas d'erreur de migration. Spécificités MySQL : Les tables doivent être au format InnoDB.En effet, ce format gère les clés étrangères, les éventuelles restrictions qui y sont attachés et la notion d'intégrité de transactions requise pour avoir des données en base cohérente entre tables. Normes de modélisation: Principe de modélisation de données Le développeur web sait que la modélisation fait appel à un outil de modélisation de données dont les caractéristiques sont le suivantes: -Modélisation conceptuelle des données par schéma entité relation : conception du modèle conceptuel de données(mcd); -Capacité à utiliser le concept de JMerise; -Capacité à réaliser des sous modèles de façon à découper fonctionnellement l application(schémas SQL);

6 -Génération d un modèle physique de données d après le MCD et ce pour différents SGBDR(Oracle, MS SQL Serveur, IBM DB2, MySQL,...), avec gestion des schémas; -Rétro ingénierie(de la base au MPD, du MPD au MCD); -Notation des modèles suivants les méthodes de JMerise; -Modélisation des héritages y compris en exclusion mutuelle, avec génération des triggers de validation d intégrité référentielle ascendante et descendante; -Génération des scripts SQL de la base de données; -Génération des scripts SQL d évolution de la base de données(delta) -Edition de la documentation technique. Dans la mesure du possible, le modèle fera appel à la notion de sous modèles afin de ne pas encombrer un seul modèle avec une quantité d objets illisible. La notion de sous modèle devra correspondre à un découpage fonctionnel dont l élément périmétrique est le schéma SQL. Rappelons qu un schéma SQL est un sous-ensemble d un catalogue SQL( un catalogue SQL= une base de données) et permet de gérer la sécurité d accès aux données de manière globale et générique. Les objets du modèle(entité, propriétés, association) seront tous annotés (description fonctionelles) Architecte de données: Une seule personne dans l entreprise aura la responsabilité de la conception du modèle de données pour une base spécifique. Ses compétences ne pourront être transférées qu en cas d indisponibilité, le but étant de garder la cohérence du modèle. Fichiers de modèles: Tout fichier généré par l applicatif sera archivé et stocké en lieu sûr de même que l historique des modifications du modèle(modèle archivé)) et les scripts différentiels. Le nom d un fichier peut indifféremment être écrit en majuscule ou en minuscule, voire une combinaison des deux. Nom des ficheirs du MCD: Le nom d un fichier de MCD sera constitué du nom du projet et d une extension spécifique à l éditeur(en général.mcd) Syntaxe: projet.mcd Nom des fichiers du MPD: Le nom d un fichier de MPD sera constitué: -du nom du projet ;

7 -d un caractère blanc souligné(underscore); -d un code numérique sur 4 positions indiquant la version du SGBDR; -d une extension spécifique à l éditeur(en général.mpd); Syntaxe:projet_code.mpd Nom des archives de MPD: Le nom d un modèle physique archivé sera constitué : -du nom du projet; -d un caractère blanc souligné(underscore); -d un code numérique sur 4 positions indiquant la version du SGBDR; -d un caractère blanc souligné(underscore); -de la date de création de l archive au format ISO court; -d une extension spécifique à l éditeur(par exemple.mpa) Syntaxe:projet_code_date.mpa Nom des scripts de création de la base de données: Le nom d un script de création de la base de données sera constitué: -du nom du projet: -d un caractère blanc souligné(underscore): -d un code numérique sur 4 positions indiquant la version du SGBDR; -de l extension.sql Syntaxe:projet_code.sql Nom des scripts différentiels: Le nom d un script de modification de la base de données généré par calcul de différence entre le dernier modèle physique archivé et le modèle physique actuel, sera constitué: -du nom du projet; -d un caractère blanc souligné(underscore); -d un code numérique sur 4 positions indiquant la version du SGBDR; -d un caractère blanc souligné(underscore); -de la date de création du script au format ISO court; -de l extension.sql Syntaxe:projet_code_date.sql Auto documentation de la base : Dans chaque modèle il sera créé différentes entités de nature à documenter la base de données. L entité de nom T_S_DATABASE_INFO_DBI contiendra les attributs suivants:

8 Colonne Type Longueur Oblig. Validité DBI_LIBELLE alphanumérique 128 oui Clef DBI_TYPE alphanumérique 12 oui 'alpha', 'entier', 'réel', 'booléen', 'date', 'heure', date-heure' DBI_VALEUR alphanumérique 256 oui (le nom de cette entité est préfixé T_S_ pour table système ) Cette entité sera transformée en une table lors de la génération du modèle physique et devra contenir au minimum les informations suivantes: DBI_LIBELLE DBI_TYPE DBI_VALEUR Nom alpha mabase Date création date SGBDR alpha MS SQL Server 2008 MCD MPD alpha alpha