Langages et normes
Voici les quelques règles sur le langage, la syntaxe et normes de développement en vigueur pour le projet Dolibarr :
Versions
- Dolibarr doit fonctionner sur:
- Tous OS (Windows, Linux, MACOS...)
- PHP 5.6.0+ (requires functions like DateTimeZone.getOffset, php-intl) (Doit fonctionner sans aucun module PHP complémentaire hors les modules d'accès base de donnée).
- Mysql 5.1+
Normes Copyright
- Tout fichier PHP doit avoir un en-tête selon le masque suivant
<?php
/* Copyright (C) YYYY John Doe <email@email.com>
*
* Licence information
*/
...
Quand vous éditez un fichier existant du projet, ajouter une ligne Copyright sous celles existantes.
Normes PHP
PHP
- Dolibarr est écrit en PHP et supporte toutes versions PHP supérieures à la 5.6.0+ (requires functions like DateTimeZone.getOffset, php-intl). Les fichiers doivent tous comporter l'extension .php
- L'appel aux variables superglobales PHP doit passer par les opérateurs dédiés $_COOKIE, $_SERVER, $_ENV. Mais pour récupérer les contenus de $_GET ou $_POST, il faut passer par la fonction dolibarr GETPOST() ou GETPOSTINT() .
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_arrays est à off. De plus, le code doit fonctionner aussi bien quand l'option PHP register_globals est à off (recommandé par PHP) 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"]. Notez aussi que le framework Dolibarr passe une routine pour rendre plus sûr le contenu du $_SERVER["PHP_SELF"] (dans le fichier main.inc.php, donc avant tout traitement métier)
- Quand plusieurs variables doivent être initialisées avec la même valeur, il faut utiliser plusieurs instructions:
$var1 = 1; $var2 = 1; $var3 = 1;
plutôt que
$var1 = $var2 = $var3 = 1;
qui est moins performant.
- Les chaines doivent avoir les variables sorties de la chaine.
print "Mon texte affiche ma ".$variable." !\n";
- Les commentaires doivent suivre la syntaxe C, ie un double antislash pour un commentaire d'une ligne et utilisation slash-étoile pour ouvrir un bloc de plusieurs lignes
/* Bloc de commentaire
*
* Fin du bloc
*/
$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);
for ($i = 1 , $i < 2 ; $i++)
{
// commentaire sur une ligne
print $i;
}
- Les fonctions doivent retourner une valeur strictement > à 0 en cas de succès, et un nombre < à 0 en cas d'erreur.
- Pas de code mort (non utilisé) dans le code principal de Dolibarr (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 classes (donc fichiers *.class.php et *.lib.php), utiliser "include" pour tout inclusion de fichier de type template ou contenant un mixte de HTML et PHP (donc fichiers *.inc.php et *.tpl.php).
- Le style de code a utiliser est le PSR-12 (https://www.php-fig.org/psr/psr-12/). Seules les règles "MUST" sont imposées. Notez aussi les points/exceptions suivants:
- La longueur des lignes: PSR-12 indique que la longueur des lignes a une limite "soft" à 120. Il est en effet préférable d'avoir de longues lignes de données de déclaration plutôt que de longues pages car ce code ne contient aucune logique intéressante ou utile, toutefois une limite "hard" a été instauré à 1000 caractères. Du code qui ira au delà provoquera des erreurs dans la plateforme d'Intégration Continue.
- Les tabulations sont acceptées : L'autre exception est qu'on ne remplace pas les tabulations systématiquement par des espaces. L'utilisation des tabulations simplifie la vie de certains développeurs. De plus, l'utilisation d'espaces rend certaines fonctions d'autoformatage défectueuses (comme sur certaines versions d'Eclipse, lors de copier-coller).
- Note 1: Les règles suivantes sont particulièrement importantes :
- Les fichiers doivent être sauvés en format Unix (LF) et non Windows (CR/LF). Le format Unix étant compatible sur les OS Unix like, Windows, Mac, alors que le format fichier texte Windows pose problème sous certains PHP sous Unix.
- Les smart tags PHP ne sont pas utilisés. Les sections de code doivent commencer par <?php
- Note 2: Vous pouvez utiliser le fichier dev/setup/codesniffer/ruleset.xml comme fichier de contrôle pour vérifier votre style de code avec PHPCodeSniffer.
- Note 3: Vous pouvez utiliser le fichier dev/setup/eclipse/PSR-12 [built-in].xml comme fichier de règles de syntax pour configurer Eclipse.
- Note 4: Vous remarquerez que le code actuel ne suit pas forcément tout cela. La raison est historique. La règle fut instaurée en cours de route, aussi, si vous trouvez du code non respectueux de ce standard, n'hésitez pas à le corriger.
Structures des classes et champs
Certaines propriétés de classes se retrouvent dans de nombreuses classes. Pour homogénéité, on utilisera les noms suivants:
- entity that is id for the multicompany feature - date_creation: date of creation - date_modification: date of last modification (often field tms in database) - date_validation: date validation - fk_user_creation: id of User of creation - fk_user_modification: id of User of last modification - fk_user_validation: id of User of validation - import_key contains the import code YYYYMMDDHHMMSS, if record was loaded with a mass import.
Normes SQL
Structure et nom 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. Sa valeur par défaut est llx_.
- Structure des tables.
Lorsque vous créez une table, il est recommandé de prendre les même conventions de nommages de tables que les autres tables Dolibarr. Avec, à minima les champs suivant:
- rowid INTEGER AUTO_INCREMENT PRIMARY KEY qui est l'id technique - entity INTEGER default 1 that is id for the multicompany feature - date_creation datetime that is the creation date - tms timestamp qui sera un champ contenant la date de chaque mise à jour (la base de donnée le gère tout seul, pas besoin de le gérer par le code) - import_key varchar(32) qui contiendra le code d'import YYYYMMDDHHMMSS si vous faites des imports en masse dans la table. - status smallint pour stocker le status d'un object
Eventuellement
- fk_user_creat integer qui est l'id du user de création (fk_user_author also found) - fk_user_modif integer qui est l'id du user de modification - fk_user_valid integer qui est l'id du user de validation - fk_soc integer qui est l'id du tiers (si applicable)
- Type des champs
Dans la pratique, afin d'être compatible avec toutes les précisions des pays, syntaxes des bases, on utilisera uniquement les types suivants:
- integer pour tout nombre entier, id ou clé étrangère (bigint éventuellement accepté pour les id des très grosses tables) - smallint pour tout numérique entier de petite taille (comme pour stocker un code de status) - double(24,8) pour tout montant - double(6,3) pour les taux de tva - real pour une quantité - varchar pour une chaîne (y compris de longueur 1, le type char est de plus en plus déprécié) - timestamp pour un champ date+heure devant être mis a jour automatiquement - datetime pour un champ date+heure - date pour un champ date
Clé primaire
La clé primaire d'une table s'appelle rowid.
Il y a quelques tables qui échappent à cette règle actuellement (ex Table llx_c_actioncomm), pour des raisons historiques. Une évolution pourra être étudiée pour une prochaine version.
Clés étrangères
Le nom d'une clé étrangère commence par le préfixe fk_ suivi du nom de la table liée (requis pour éviter doublons globales à la base, problématiques sous certains SGBD comme postgresql) puis du champ lié (pour permettre plusieurs clés étrangères différentes sur une même table).
Exemple: fk_facture_fourn_fk_soc
Note: Si vous développez votre propre module externe, il ne doit pas y avoir de clé étrangère depuis vos tables qui pointent sur les tables standards de Dolibarr. Ceci casserait les fonctionnalités de mise à jour, de réparation, de sauvegardes et de restauration et ces processus ne doivent pas dépendre de la présence d'un module externe. Il vous faut donc assurer l'intégrité de manière applicative si nécessaire.
Clés alternatives
Parfois, il n'y a pas que la clé primaire 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 (requis pour éviter doublons d'index globals à la base, problématiques sous certains SGBD comme postgresql) puis d'un suffixe qui caractérise la clé (pour permettre plusieurs index uniques sur une même table).
Exemple: uk_societe_code_client
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éfix idx_ puis le nom de la table et le nom du champ sur lequel porte l'index.
Exemple: idx_societe_user_creat
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 tables: 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 <email@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 <http://www.gnu.org/licenses/>.
-- ===========================================================================
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;
Exemple fichier clés/index llx_matable.key.sql:
-- ===========================================================================
-- Copyright (C) 2008 Author <email@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 <http://www.gnu.org/licenses/>.
-- ===========================================================================
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 de champs
Dans le cas des select on pourra utiliser les alias pour simplifier l'écriture des requêtes:
select chp1, chpxxx2 as chp2 from table2 as t1, table2 as t2 where t1.chpx = t2.chpy
Toutefois, il ne faut pas utiliser ces alias sur des requêtes update car non compatible avec mysql 3.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 real. Les quotes sur les numériques de type float provoquent parfois un stockage d'une valeur différente. Par exemple 412.62 dans le insert sera en fait stocké avec la valeur 412.61999512 en base (suite à des conversions chaines-numériques implicites) si le champ est de type double(24,8). Et seul le PHP voit 412.61999512. 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 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', 412.62)
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 languages 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' (si il s'agit d'un prix unitaire), 'MT' (s'il s'agit d'un prix total) ou 'MS' (autres cas) selon le besoin. Voir aussi le chapitre "Les nombres réels, montants et calculs" plus bas.
- Les fonctions SQL de date NOW, SYSDATE, DATEDIFF sont interdites au sein des ordres SQL. S'il faut saisir la date du moment dans un champ, la valeur doit venir du PHP, par exemple par la fonction dol_now(), et non du moteur de base de données. Ceci pour les raisons suivantes:
- afin d'avoir une meilleure portabilité du code
- avoir une gestion correcte des TimeZone et ne pas dépendre du TimeZone de la base de donnée (le timezone de réference est le timezone de PHP et le timezone de la base de données peut être différent de celui-ci, aussi les conversions de date doivent se faire toute côté PHP).
- meilleurs performances (voir exemples et commentaire plus loin)
Par exemple, on ne fera pas:
$sql="SELECT rowid FROM table where datefield = NOW()";
mais:
$sql="SELECT rowid FROM table where datefield = '".$this->db->idate(dol_now())."'";
Par exemple, on ne fera pas:
$sql="SELECT rowid FROM table where DATEDIFF(table.datefield, NOW()) > 7";
mais:
$sql="SELECT rowid FROM table where datefield < '".$this->db->idate(dol_now() - (7 * 24 * 3600))."'";
Un autre avantage de cette règle est que la requête peut bénéficier de l'utilisation de l'index puisqu'on compare datefield à une valeur fixe. Dans le cas du datediff, on applique un traitement sur le champ avant comparaison, rendant impossible l'utilisation de l'index de ce champ. Les conséquences sont des performances très dégradées par rapport à la version sans datediff.
- L'instruction WITH ROLLUP est interdite :
Cette instruction ne doit pas être utilisée : Elle n'est pas gérée de la même manière par des bases de données différentes. De plus, l'utilisation de WITH ROLLUP brise la pureté des données retournées. L'agrégation intermédiaire de génération de sous-totaux réalisée par cette instruction peut facilement être effectuée à l'aide de PHP et permet de conserver le tableau de données retourné propre (non corrompu par des données insérées artificiellement). Outres son côté pas bien standardisé, en insérant des résultats de calculs au sein des données, donnant un résultat qui est un mixe donnée et calculs métiers d'aggrégation, la compréhension du code se trouve compliqué et même les évolutions du code sur ces agrégations plus possibles lorsque se complexifient.
- Utilisez $db->ifsql pour le IF SQL
N'incluez pas le IF dans votre requête SQL générée. Mais utilisez plutôt la méthode $db->ifsql() pour créer un SQL IF compatible avec toutes les bases de données SQL.
- Pas de DELETE CASCADE et ON UPDATE CASCADE
De telles instructions SQL sont interdites car elles contournent les règles métiers de l'application. Par exemple, s'il existe une cascade de suppression entre la table A et B, lorsque l'application exécutera le code pour supprimer un enregistrement dans A, les enfants de la table B seront également supprimés. S'il y a eu un trigger Dolibarr PHP (par exemple apporté par un module externe) sur la suppression de l'enregistrement de B (par exemple pour valider la suppression ou pour exécuter une action complémentaire), la DELETE CASCADE sera exécutée sans avoir le trigger Dolibarr PHP exécuté, manquant la validation ou les actions du déclencheur PHP du module. Donc toutes les règles métiers doivent être implémentées du même côté (côté serveur PHP), c'est la raison pour laquelle les règles métier implémentées sur Database ne sont pas autorisées (même situation que le point suivant sur les triggers Database)
Règles de migration de base
- Les scripts de migration de structure sont les fichiers de type install/mysql/migration/a.b.c-x.y.z.sql. Dans un fichier de migration de n vers n+1, on ne détruit 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ées et la notion d'intégrité de transactions requise pour avoir des données en base cohérente entre tables.
- Dolibarr DOIT fonctionner même avec les options strict de Mysql active.
Pour l'activer (fortement recommandé en développement), ajouter la ligne suivante dans le fichier config du serveur Mysql (my.cnf ou my.ini)
sql-mode="STRICT_ALL_TABLES,ONLY_FULL_GROUP_BY,NO_ZERO_DATE,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
Spécificités PostgreSQL
Seuls les fichiers pour Mysql doivent être maintenus. Les fichiers pour les autres bases sont convertis "à la volée" par le driver Dolibarr de la base.
Il existe une exception. Les requêtes "UPDATE FROM" : Syntax MySQL :
UPDATE table_taget as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid;
Syntax PgSQL:
UPDATE table_taget as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid;
Il n'en existe pas dans Dolibarr, mais pour vos modules Vous devriez faire tel que :
if ($this->db->type=='pgsql') {
$sql="UPDATE table_taget as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid";
} else {
$sql= "UPDATE table_taget as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid";
}
Normes HTML
- Tous les attributs dans les balises HTML doivent être *en minuscule* et quotés avec des *doubles quote*.
- Les liens href doivent être absolus en se basant sur la fonction dol_buildpath() obtenir un chemin absolu depuis un chemin relatif au répertoire htdocs (pour les modules externes) ou en utilisant DOL_URL_ROOT pour le code core. Pour les tags img, il faut faire appel à la fonction img_picto().
Par example:
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
print '<a href="'.DOL_URL_ROOT.'/repducore/pageducore.php">'.img_picto('Texte alt','nompictopng','').'</a>';
- Les tables HTML doivent avoir des colonnes sans valeurs forcées, excepté pour les colonnes qui contiennent une information dont la longueur est non variable. Par exemple, une colonne avec un picto peut être forcée à with="20px". Dans les autres cas, il faut éviter de forcer la largeur des colonnes. La raison est que, dans la plupart des cas, le navigateur fait un meilleur travail pour définir automatiquement la bonne largeur des colonnes qu'en forçant manuellement les largeurs. Et ceci marche quelle que soit la résolution de l'écran.
- Le javascript/ajax et l'appel aux scripts java dans les pages php est à proscrire. Si toutefois du code javascript est inclus, il doit être conditionné par le test sur "$conf->use_javascript_ajax"
if ($conf->use_javascript_ajax) {
... // Le code php qui génère du javascript est ici
}
- Les popups windows ne doivent pas être utilisées, sauf pour des tooltips (et restent conditionnées par le point ci-dessus).
- Les scripts externes sont écrits en Perl s'ils ne peuvent l'être en php, l'utilisation d'un autre langage n'est pas interdit mais doit être discuté au préalable dans la mailing list des développeurs.
Normes Dolibarr et squelettes de code
Squelettes de code
Afin d'uniformiser le code et d'accélérer le développement de nouveaux composants dans Dolibarr, se trouvent dans le répertoire htdocs/modulebuilder/templates.
Par exemple:
- 1 fichier qui sert d'exemple de descripteur de module: core/modules/myModule.class.php
- 1 fichier qui sert d'exemple de code pour faire une nouvelle classe: class/skeleton_class.class.php
- 1 fichier qui sert d'exemple de code pour faire une nouvelle page: skeleton_page.php
- 1 fichier qui sert d'exemple de code pour faire un script à exécuter en ligne de commande: scripts/skeleton_script.php
...
Servez-vous en comme exemple. Notons que ces squelettes sont aussi utilisés par le générateur de code PHP (Module ModuleBuilder) qui est décrit dans la chapitre de développement de module Dolibarr pour accélérer vos développements.
Variables globales
Certaines informations ou objets sont communs et fixes pour toute l'exécution d'une page PHP et doivent être utilisés presque partout dans le code. Pour éviter de propager partout ces informations ou objets, ils sont stockés dans des variables globales auxquelles vous pouvez accéder partout. Ces variables globales sont initialisées au début de chaque appel PHP (dans le master.inc.php ou master.inc.php ou en haut de la page). Ces objets ne sont normalement instanciés qu’une seule fois. La liste des variables globales disponibles est définie ici : $user, $conf, $db, $langs, $mysoc, $hookmanager, $extrafields
- $conf est l'objet qui contient la configuration (enregistrée dans la base de données)
- $user est l'objet de l'utilisateur actuel
- $mysoc est l'objet contenant toutes les informations sur l'entreprise actuelle
- $langs est l'objet avec la langue actuelle
- $db est le gestionnaire de base de données de la connexion actuelle à la base de données
- $hookmanager est une classe d'usine pour gérer les hooks
- $extrafields est une classe d'usine pour gérer les extrafields
Les dates et TimeZone
Dolibarr se veut une application multi-utilisateur et multi-localisation. Il convient donc de stocker les dates dans le bon format. Pour éviter les problèmes de conversion, les règles suivantes doivent être appliquées:
- Une date en mémoire doit être au format Timestamp GMT.
- Une date stockée en base de données contient le Timestamp issue de la date soumise dans la requête en heure locale du serveur PHP. Cela ne concerne pas les dates mises à jour automatiquement par la base (champ tms en base).
Ainsi le 1er janvier 1970, 3 heures à Paris (TZ=+1) = 1er janvier 1970, 2 heures à Greenwich (TZ=0) sera stocké en mémoire par 7200 et sera soumis à la base de données avec la chaine '19700101030000' (PHP convertit en heure de son TZ et la base déconvertit avec son TZ qui est le même que celui de PHP).
Les méthodes select doivent donc traduire les champs dates lus qui sont au format chaine TZ de la base ('19700101030000') par appel de la méthode db->jdate afin de récupérer une information en mémoire au format Timestamp GMT. Et les méthodes insert doivent lors de la génération de la requête convertir la date mémoire connue en variable, par la méthode db->idate (Voir exemples générés par le squelette).
- Les dates mises à jour automatiquement par la base (champ tms en base) contiennent le Timestamp où la modification est faite selon le timezone de la base de donnée. Les méthodes select récupèrent cette donnée en mémoire au format Timestamp GMT en appliquant également le db->jdate. Si le timezone de la base de donnée diffère de celui du PHP (un des 2 est mal réglé), il peut donc y avoir des écarts entre date de création et modification.
- La manipulation de dates en PHP doit être faite en utilisant les fonctions dates de Dolibarr: dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree(). Vous trouverez également d'autres fonctions prêtes à l'emploi dans le fichier date.lib.php.
L'encodage UTF8/ISO
Dolibarr stocke les informations de manière suivante:
- En base de donnée, les données sont en UTF8 ou ISO. Cela dépend du pagecode de la base, donc des options à la création de cette base. Dans tous les cas le driver d'accès base Dolibarr (dans /lib/database) s'arrange à la lecture et insertion pour convertir vers et depuis de l'UTF8.
- Les données en mémoires sont donc stockées en UTF8 (instances d'objets PHP).
- Les pages web affichées à l'écran sont au format UTF8
Les nombres réels, montants et calculs
En PHP comme dans d'autres langages (Java par exemple), les données non entières (float, real, double) ne sont pas fiables. Essayer de faire par exemple
print 239.2 - 229.3 - 9.9;
Vous n'obtiendrez pas zéro mais un nombre très petit en puissance de 10 négative. Si vous obtenez zéro, vous pourrez trouvez d'autres exemples qui ne fonctionnent pas. Le problème des float est général, une variable résultante de calcul de nombre réels doit SYSTEMATIQUEMENT être nettoyée par la fonction price2num() avec le 2eme paramètre renseigné à: 'MU', 'MT' ou 'MS' selon le besoin (voir doc fonction).
print price2num(239.2 - 229.3 - 9.9, 'MT');
S'il ne s'agit pas d'un prix sur lequel s'adapte les paramètres MU, MT ou MS, il faut utiliser la fonction round().
Création de tables
Ne pas créer de table à l'utilisation, c'est-à-dire à la première utilisation du module. Si vous créez un module qui utilise des tables qui ne sont pas intégrées en standard dans le code de Dolibarr, veillez à suivre le didacticiel Développement module qui explique comment joindre des tables qui se créent à l'activation du module et non à son utilisation (voir plus haut).
Comparer la version
Si votre code a besoin de faire des choses différentes selon la version de Dolibarr, vous pouvez utiliser le truc suivant pour comparer les versions
$version=preg_split('/[\.-]/',DOL_VERSION);
if (versioncompare($version,array(5,0,-4)) >= 0) { //mycode for 5.0 only; } // For dolibarr 5.0.* (the -4 means we include also alpha, beta, rc and rcX)
Mais cette solution requiert de faire un include avoir la fonction versioncompare. Une alternative est d'utiliser le test suivant:
if ((float) DOL_VERSION >= 5.0) { //mycode for 5.0 only; } // For dolibarr 5.0.*
Logs
Ajouter des traces dans votre code avec la fonction
dol_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);
Répertoires de travail
Si vous avez besoin de créer un répertoire de travail, dans votre code, faites référence à ce répertoire par DOL_DATA_ROOT.'/monmodule'
Le répertoire peut être créé dans votre code à l'exécution par le code suivant:
$mymoduledir=DOL_DATA_ROOT.'/monmodule';
dol_mkdir($mymoduledir);
Si vous avez besoin d'un répertoire qui contiendra des données temporaires, ce répertoire doit être DOL_DATA_ROOT.'/monmodule/temp'
Design patterns et programmation objet
Design patterns de Création (GoF)
Design patterns définis par le Gang Of Four (voir la wikipédia sur les Design patterns). Dans Dolibarr, pas de mise en oeuvre de design patterns de comportement particulier. On trouve des objets proches des Singletons et Fabriques conformes à 100% dans l'esprit mais pas dans la syntaxe, ceci afin d’être compatible avec la plus large plage possible de versions de PHP.
Design patterns d'entreprises (Martin Fowler)
Mode d'organisation du code
Martin Fowler a identifié 3 méthodes d'organisation du code appelées patterns (motifs):
- Le Transaction Script (Le code est linéaire en fonction d'une action utilisateur).
C'est le motif à l'ancienne utilisé dans les langages procéduraux. Inconvénient: Redondance du code. Nécessité de connaitre le modèle physique pour développer les parties métiers.
- Le Domain Model
C'est un concept possible depuis les langages objets. Ce sont les procédures métiers (qui doivent être identifiés avant) qui servent de bases pour les classes objets. Inconvénient : Motif complexe à maintenir.
- Le Table Module
Un intermédiaire entre les 2 précédents où l'on a une instance unique de classe par table de la base de données.
-> Comme le montre les squelettes de code (voir point précédent), Dolibarr se base sur le principe du Table Module.
Communication Logique métier - Données (ORM)
Il existe 3 modes de liaisons:
- Le Table And Row Data Gateway
C'est le plus simple. On crée une classe par table et chaque classe est un pont avec la table correspondante et propose les méthodes CRUD sur cette table (Create, Read, Update, Delete). Une instance de classe étant alors un enregistrement de la table. La classe ne contient que du code d'accès aux lignes ou colonnes de tables. Le code métier doit alors être ajouté dans d'autres classes. Les liens entre ces classes tables et les classes métiers devant être connues ou déduites de la connaissance du développeur.
Exemple: C'est le mode mis en oeuvre quand on utilise certains Frameworks d'ORM comme iBatis (http://ibatis.apache.org/).
- Le Active Record
Identique au précédent, mais on se permet d'ajouter quelques fonctions métiers sur la classe, à condition que ces fonctions soient bien propres à la table ou à la notion métier portée par l'enregistrement. C'est le pattern qui offre le meilleur rapport fonctionnalité/complexité.
Exemple: C'est le mode choisi pour les développements Dolibarr et de nombreuses autres applications PHP qui ont leur propre framework et pratiques de développement.
- Le Data Mapper
Les classes représentent les entités du problème et non les données. Il faut donc doubler, tripler... ces classes avec des classes Mapper pour accéder aux données. Plus "puriste" sur le papier car plus proche du métier, ce mode a aussi l'inconvénient d'être très complexe et difficile à maintenir dans la réalité (l'expérience pratique constatée ne rejoignant pas les promesses de la théorie).
Exemple: C'est le choix si on utilise le Framework d'ORM Propel (https://propelorm.org/). On le trouve donc sur des applications plus lourdes basées sur cet ORM entre autres.
-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison Active Record qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre).
Design Pattern d'Interface Graphique (MVC)
Il existe plusieurs design pattern pour les interfaces utilisateurs (MVC, MVP, MVVM). Beaucoup confonde ce design pattern avec celui consistant à utiliser un framework de templates. C'est sans rapport. Un framework de templates (voir point précédent) n'est en lien qu'avec la partie "V" de ces modèles.
-> Dolibarr utilise le Design Pattern MVC (Model - Vue - Contrôleur). La partie M est matérialisée par une classe DAO contenant les méthode CRUD (Create-Read-Update-Delete) d'accès à la table. Beaucoup de frameworks ont fait le choix de mettre la partie de code C (Contrôleur) et la partie de code du V (vue) dans des fichiers, voir même répertoires séparés. La maintenance semble plus aisé sur la papier, en pratique, il faut sans arrêt jongler entre n fichiers, le C étant fortement lié au V. Aussi dans Dolibarr, la séparation est faite par une simple section de commentaire. La partie de code C (Contrôleur) est donc le code qui se trouve sont la balise
/* * Actions */
Elle est suivi par la partie de code V (Vue), bien séparé du C par la balise
/* * View */
Ce mode de séparation a eu un effet neutre sur les nouveaux développement mais a permis de réduire de manière si importante le temps requis pour la maintenance et correction de bugs qu'il n'est pas envisagé de basculer vers un autre type de séparation (les constats faits dans la vraie vie ne sont pas toujours ceux attendus par la théorie scolaire). L'important reste qu'il y ait toujours séparation entre le C et le V pour être MVC, peu importe comment est matérialisée cette séparation, du moment qu'elle l'est (Rappel: Ne pas confondre la notion de séparation du C et du V qui relève du design pattern MVC avec la notion de séparation du code pour alimenter les données d'une Vue et du code pour formater la Vue, cette deuxième notion étant un principe de séparation relevant du Design Pattern de Vue, autrement appelé notion de templates, sans lien avec le MVC donc, voir point suivant).
Design Pattern de Vue - Présentation
Il existe des frameworks spécialisés dans le Design Pattern de Vue, la partie qui consiste à formater l'écran vue par l'utilisateur. Les vieilles versions de Dolibarr utilisaient Smarty. Ce framework est une surcouche à un Framework, déjà très puissant, de formatage d'écran nommé... PHP. Les bénéfices étant très inférieurs aux inconvénients, il a été abandonné au profit de templates PHP (fichiers .php ou .tpl.php) qui restent le plus simple, le plus universel, le plus évolutif et le plus performant des frameworks de présentation.
Son seul défaut est qu'il ne peut garantir à 100% les écarts d'un développeur qui irait intégrer dans la Vue, une logique sans rapport avec la présentation (donc autre que du code à vocation de génération, de formatage, de sortie HTML, de logique de test ou de boucle pour le rendering écran). Ce point est toutefois contrôlé par le mécanisme de validation du code des chefs de projets.
La encore, c'est l'expérience et le constat "sur le terrain" d'un meilleur rendement de productivité, d'évolution applicative et de performance qui a motivé l'abandon des frameworks de Présentation externes au profit du framework PHP.