Pour faciliter sa lecture, le code doit respecter des règles de mise en forme appliquées à l'ensemble des sources. Les règles ci-dessous sont celles appliquées depuis l'origine du projet.
Les principales règles concernant le code Java dans Lutece sont :
La présentation générale des fichiers devra respecter celle existante (pour les classes java la présentation des commentaires, indentation du code, utilisation de l’anglais.)
L’ensemble de l’application doit conserver une homogénéité complète tant sur la présentation du code que sur les règles de nommages, l’utilisation de l’anglais, l’insertion de commentaires.
Tous les fichiers sources doivent comporter la licence de diffusion en entête.
La mise en forme du code doit se faire via Maven à l'aide de l'outil Jalopy dont les règles sont référencées dans les fichiers POM parents.
Voici la commande à lancer à la racine du projet :
$ mvn jalopy:format
Le code HTML doit être correctement indenté et respecter la norme HTML 5.0 (http://www.w3.org/TR/html5/).
Les fichiers doivent être encodés en UTF-8.
L'usage du javascript doit être limité au maximum en raison des problèmes d'accessibilité engendrés et des problèmes liés aux utilisateurs qui désactivent l'exécution des scripts dans leurs navigateurs.
Attention : L'application doit impérativement rester opérationnelle lorsque les scripts sont désactivés.
Tous les attributs de mise en forme du code HTML doivent être gérés par des feuilles de style CSS3 dont les spécifications sont définies par le W3C (http://www.w3.org/Style/CSS/).
Les styles devront utiliser au maximum l'héritage et les surcharges devront être limitées au maximum.
Toutes les requêtes SQL (présentes dans les scripts SQL ou dans les DAO) doivent suivre la liste de règles ci-dessous afin de respecter au maximum la norme SQL-92. Tous les formats de données ou syntaxes spécifiques à un Système de Gestion de Base de Données (SGBD) doivent être évités afin de garantir la possibilité d'utilisation de Lutèce avec différents SGBD.
| Description | Exemple de syntaxe SQL spécifique (MySQL) | Syntaxe SQL-92 équivalente à utiliser |
| Les caractères anti-côtes utilisés pour les noms de tables ou de colonnes doivent être supprimés | CREATE TABLE `core_admin_auth_db_module` | CREATE TABLE core_admin_auth_db_module |
| La définition de l'encodage pour une colonne ou une table doit être supprimée | CREATE TABLE ... (access_code VARCHAR(16) collate utf8_unicode_ci, | CREATE TABLE ... (access_code VARCHAR(16), |
| Lors de la création d'une table, pour une colonne, la déclaration de la valeur par défaut et le fait que cette colonne puisse stocker une valeur NULL doit respecter un ordre donné | CREATE TABLE ... (access_code VARCHAR(16) NOT NULL DEFAULT | CREATE TABLE ... (access_code VARCHAR(16) DEFAULT '' NOT NULL, |
| Lors de la création d'une table, le moteur de stockage ainsi que l'encodage ne doivent pas être spécifiés | CREATE TABLE ... ( ... ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; | CREATE TABLE ... ( ... ); |
| Les tailles des champs de type entier (INT, SMALLINT, ...) ne doivent pas être spécifiées | CREATE TABLE ... (id_mailinglist INT(11)NOT NULL DEFAULT '0', | CREATE TABLE ... (id_mailinglist INT NOT NULL DEFAULT '0', |
| Suppression des types de données non signées. | CREATE TABLE ... (id_mailinglist INT UNSIGNEDNOT NULL DEFAULT '0', | CREATE TABLE ... (id_mailinglist INT NOT NULL DEFAULT '0', |
| Déclaration des index de manière explicite et non lors de la définition de la table | CREATE TABLE core_admin_right ( ... , KEY index_right (level_right, admin_url)) | CREATE TABLE core_admin_right ( ... );CREATE INDEX index_right ON core_admin_right (level_right, admin_url); |
| Ne pas utiliser la fonctionnalité ON UPDATE CURRENT_TIMESTAMP permettant de mettre à jour un champ date lors de la mise à jour d'un tuple. | CREATE TABLE ... ( date_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL ON UPDATE CURRENT_TIMESTAMP); | CREATE TABLE ... ( date_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL); |
| Ne pas utiliser le types de données TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Attention utiliser LONG VARCHAR écrit en deux mots. | TINYTEXT;MEDIUMTEXT;LONGTEXT | VARCHAR(255)LONG VARCHARLONG VARCHARLONG VARCHAR |
| Ne pas utiliser le types de données TINYBLOB, BLOB, LONGBLOB | TINYBLOB BLOB LONGBLOB | VARBINARYLONG VARBINARYLONG VARBINARYLONG |
| Ne pas utiliser le type TINYINT | CREATE TABLE ... ( status TINYINT); | CREATE TABLE ... ( status SMALLINT); |
| Suppression des commentaires MySQL générés lors de l'export d'une table par exemple. | /*!40101 SET NAMES utf8 */; | aucun commentaire |
| Ne pas utiliser le caractère d'échappement antislash. Pour échapper une simple cote, il faut doubler chaque simple cote. Ne pas utiliser de double cote pour délimiter un champ, utiliser une simple cote. | L\'accès aux ressourcesINSERT INTO core_admin_right VALUES (contenu)Retour chariot\r\nNouvelle ligne | L''accès aux ressourcesINSERT INTO core_admin_right VALUES ('contenu')Retour chariotbr /Nouvelle ligne |
| Pour limiter les risques d'incompatibilité, toujours préférer stocker les données en binaire lorsque cela est possible | INSERT INTO core_stylesheet (... ) VALUES ( 'xsl:stylesheet version=1.0...' ) | INSERT INTO core_stylesheet (... ) VALUES ( 0x3C3F786D6C207665) |
L’ensemble des éléments de l’application (programmes, scripts, fichiers de propriétés, …) devra être commenté. Les commentaires devront être rédigés en anglais.
Pour les programmes Java, l’ensemble des classes et de leurs méthodes (y compris protected et private) devra comporter des commentaires Javadoc contenant une description de la fonctionnalité prise en charge par la méthode, ainsi que les tags @param @return @exception .
Les modifications réalisées dans les versions successives seront indiquées par des tags @version .
Les nouvelles méthodes et classes des API indiqueront leur version d'introduction à l'aide de la balise @since .
Les methodes obsolètes seront identifiées à l'aide de la balise @deprecated .
Dans le cadre de l'article 47 de la loi n°2005-102 du 12 février 2005, les collectivités territoriales doivent rendre accessibles leurs sites web à chaque citoyen quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales.
Article 47 de la loi n° 2005-102
Les services de communication publique en ligne des services de l'Etat, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées. L'accessibilité des services de communication publique en ligne concerne l'accès à tout type d'information sous forme numérique quels que soient le moyen d'accès, les contenus et le mode de consultation. Les recommandations internationales pour l'accessibilité de l'internet doivent être appliquées pour les services de communication publique en ligne. Les règles décrites à l’annexe 6.4 rappellent la liste des règles relatives à l’accessibilité établies par l’Agence pour le Développement de l’Administration Electronique (ADAE)
Lutece est un outil réalisé et utilisé par une collectivité, et à ce titre intègre dans ses règles de développements les contraintes liées au respect du Référentiel Général d'Accessibilité des Administrations (RGAA).
--> le code html/css/javascript des page web notamment doit absolument prendre en compte ces contraintes. L'usage du framework Twitter Boostrap3.x permet de respecter une partie de ces normes, mais il est important de s'assurer lors du développement des fonctionnalités que les problématiques d'accessibilité soient bien prises en comptes. En doublant par exemple les fonctionnalités en javascript par des fonctionnalités gérées côté serveur en cas de désactivation du javascript par les outils d'accessibilité.
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.