Pour faire suite à la PR #251

Il n'y a pas lieu de passer les identifiants des mesures du référentiel au constructeur de la classe Mesures. On doit pouvoir faire le test sur le nombre de mesures complétées dans MesuresGenerales#statutSaisie.

… Afin de faciliter la maintenance en cas d'éventuel changement d'adresse de contact.

À l'heure actuelle, on déclare la saisie d'une donnée comme facultative en surchargeant proprieteSaisie dans la classe métier. Cela entraîne une anomalie toutefois, en ce sens que le statut de saisie ne peut plus être dans l'état « à saisir » – vu qu'un des attributs est considéré comme rempli.

Il convient de corriger cette anomalie en se dotant d'une déclaration plus propre des données facultatives, et en les gérant correctement dans le calcul de statutSaisie.

Suite à PR #253 –

La règle « si application mobile sélectionnée, alors ajouter mesure de téléchargements officiels » se retrouve spécifiée à deux endroits. Il serait bien de supprimer cette duplication.

Plusieurs pistes de réflexion :

• cumuler les profils (et donc de chaîner les concat•filter) ?
• composer les profils (et donc pouvoir ajouter dans les critères d'application d'un profil une règle de type profil: "autreProfil"?

Mon premier dossier a été aussitôt dupliqué : après avoir suivi le parcours création avec description du service puis saisie de l'état des mesures de sécurisation, j'ai obtenu deux dossiers avec le même nom de service, l'un avec la page "sécuriser" telle que je l'ai renseignée, l'autre sans (uniquement initiation du dossier avec sa description).

Ensuite, dans la page "décrire" de chaque dossier, la requête PUT du bouton "enregistrer" déclenchait une erreur 422 Unprocessable entity. dont la pile incluait un message "Le nom du service ... existe déjà pour une autre homologation".

Une fois modifié le nom d'un des dossiers, la page "décrire" se comporte de nouveau normalement.

Suggestions :

• comprendre pourquoi le dossier a été dupliqué lors des premières étapes de sa création
• permettre la suppression d'un dossier.

La page « À propos » indique que la solution est construite par /ut7. Depuis l'attribution du nouveau marché, il serait intéressant de mentionner également Omnicité.

Il manque un t : interdictionPartageVente.

Cette correction nécessite une migration des données existantes.

(… Et peut-être déplacer la classe ActeurHomologation en ActeurHomologationSpecifique.)

L'idée serait de pouvoir abstraire la fonction descriptionRole actuellement présente dans RolesResponsabilites et de pouvoir s'appuyer sur le polymorphisme pour gérer ces données.

À voir suivant comment va évoluer cette fonctionnalité.

… De la même manière qu'on le fait pour le chargement des CSS.

Actuellement, arrangeParametresMesures fait des hypothèses un peu abusives en disant que si le nom du paramètre ne commence pas par modalites-, c'est que la donnée est un statut. Cela limite les possibilités d'ajouter d'autres champs de saisie.

À voir suivant la manière dont la page « Mesures » va évoluer.

Les questions sont répétées, les styles sont répétés, les ancres sont répétées… Peut-être qu'on pourrait plus simplement décrire les questions fréquentes dans les données du référentiel. Reste à voir comment faire pour intégrer proprement des balises HTML dans ces données.

Suite à PR #253 –

applicationAchettee -> applicationAchetee

Actuellement, si on confirme la lecture du formulaire des risques sans saisir les niveaux de gravité, le statut de saisie est « complété », alors qu'il devrait être « à compléter ».

Aujourd'hui la plupart des objets émis par le référentiel sont des adresses d'un même objet en mémoire. Si jamais ces objets sont modifiés, toutes les classes accédant à ces objets récupèrent des objets modifiés. Le référentiel doit rester un singleton, mais doit devenir immutable.

NB : quelque chose a déjà été fait concernant les mesures récupérées depuis le référentiel (cf PR #436). Il faudrait étendre ce mécanisme aux autres objets du référentiel.

Plutôt que …General, mettre …Generique - et opposer à ce concept …Specifique
Cela concerne pour l'instant :

• les risques
• les mesures
• les fonctionnalites

… car la méthode click de jQuery est dépréciée depuis la v3.3

Ce module commence à ne plus être trivial, et mérite d'être testé pour pouvoir par la suite faciliter les remaniements.

Ce code se trouve couplé à public/homologation/formulaireInformationsGenerales.js (on doit notamment bouger le code si dans ce deuxième module on ajoute un bloc ElementsAjoutables). Par ailleurs, dans ce code a plusieurs responsabilités, à la fois de gérer le comportement de la pop-up modale d'alerte sur la criticité et la mise en forme des paramètres à transmettre au serveur lors du POST ou du PUT.

On doit pouvoir faire mieux 🙂 Peut-être en déplaçant une partie de ce code vers public/homologation/formulaireInformationsGenerales.js, une autre partie vers un nouveau module public/modules/modaleInformationsGenerales.js qui serait appelé depuis src/vues/fragments/modaleInformationsGenerales.pug ?

Séparer les composants…

• qui concernent la manipulation de données (et ces composants seraient testés)
• qui concernent les fragments HTML
• qui concernent l'utilisation de jQuery et la gestion des événements

La généralisation des script(id = '…', type = 'application/json') !{JSON.stringify(homologation.XXX.YYY.toJSON()) }devient de plus en plus problématique. D'une part, la duplication n'est pas heureuse, d'autre part on génére de plus en plus de comportements liés à des variables globales.

À la place, on souhaite ne plus avoir besoin de transmettre ainsi les données du PUG vers le module JavaScript correspondant :

• en passant plutôt par des data attributes
• en gérant les index qui serviront d'identifiants depuis le PUG, ou depuis jQuery
• etc.

Il y a actuellement six classes différentes qui représentent les risques et qui sont dans l'arborescence /src/modeles. Il serait intéressant de déplacer ces classes dans un répertoire dédié /src/modeles/risques.

Actuellement, les pages client qui font intervenir la création / suppression d'items dans une liste (ex. points accès, entités externes, mesures spécifiques, etc.) transmettent un tableau dont le premier élément est null. Cela est dû au fait que la première zone de saisie créée quand on clique sur « ajouter un nouvel item » se base sur un index qui vaut 1 – alors qu'il devrait valoir 0.

Bien sûr, on pourrait décréter que la valeur initiale de l'index, avant première création (et donc avant première incrémentation) vaudrait -1 – mais le fait qu'il faille changer ce changement à plusieurs endroits suggère peut-être une duplication, et l'idée que la gestion de cet index et son incrément devrait avoir lieu à un même endroit, de manière encapsulée.

Maintenant qu'on passe par MSS pour charger les bibliothèques tierces côté client, il faut aussi spécifier les chemins pour les fichiers *.map (cf. warnings dans Chrome).

Pour plus d'infos, voir par exemple https://developer.chrome.com/blog/sourcemaps/

Actuellement, dans la classe métier PointAcces, on a une méthode statique qui décrit les propriétés atomiques liées à cette classe. Il serait bien de…

• appeler cette méthode statique pour instancier l'objet
• généraliser ce principe aux autres classes filles de InformationsHomologation
• en profiter pour peut-être revoir le filtrage des données de listes dans le routeur mss.js (ex., entitesExternes, etc.)
• en profiter pour supprimer la duplication avec middleware.aseptise('liste.*.propriete')