En 4.0.P25, j’ai du code custom intégré dans la ressource SCRIPT de la disposition responsive dans la section document.on(“ui.ready”). Cette ressource était initialement dans le module système UI et a été repositionnée dans un de nos modules pour être intégré dans notre process de delivery standard.
Lorsque je livre le module concerné sur une nouvelle instance 5.1.2, j’ai un message d’erreur ERR_MODULE bloquant (car la ressource sur le point d’être intégrée existe déjà dans un module système).
Quelle est la préconisation d’intégration de ce type de code spécifique en v5 ? (la seule solution que je vois pour l’instant est de préempter à nouveau la ressource en tant que designer et de la repositionner à nouveau dans mon module métier )
Oui il y a un pb d’oeuf et de poule ici… c’est effectivement une ressource faite pour être customisée mais on la livre vide pour qu’elle existe, donc dans un module système.
PS: Que contient ce JS global ? S’agit il vraiment de choses partagées ? Sinon il faut associer des ressources aux objets metier ou objets externes
Merci pour ton retour rapide
Oui, ce sont des fonctions partagées entre toutes nos pages d’accueil de groupe et instanciées lorsque la page d’accueil est prête : activation de mécanismes de synchronisation entre des vues TCD et des vues listes avec pilotage des filtres en cliquant sur les tableaux et autres ajustements cosmétiques des TCD…
Il faut avoir le droit de modifier le système et ne pas être que ADMIN quand on change certains composants socles. Le user qui livre doit aussi avoir le paramètre :
ADMIN_SYSTEM = yes
Il faudrait effectivement gérer des exceptions pour les ressources livrées vides pour être déplacées dans d’autres modules.
Les exceptions sont, à minima, ces deux ressources SCRIPT et STYLES associés à la disposition default qui sont faites pour être customisées, les autres cas sont plus atypiques car il s’agit alors de modifier des choses système pas à priori prévues pour être customisées
Alors en effet, nous avions pris le parti de la ressource SCRIPT de la disposition responsive mais si la ressource SCRIPT de la disposition default est utilisée dans les mêmes contextes, il suffit que nous déplacions ce code dans cette ressource… c’est ça ?
Non le script est au bon endroit. C’est vrai qu’on livre toujours avec “designer” et on n’avait jamais rencontré ce cas. Le flag ADMIN_SYSTEM = no c’est plus un garde-fou pour un développeur sur la UI, donc pas de mauvaise pratique à livrer avec un super-admin.
Simplicité doit gérer des exceptions sur les ressources des dispositions pour être surchargées, comme généralement le FOOTER. On est comme pour le “context.xml” dans tomcat qui doit être à la fois rigide et ouvert. Si on casse MENU, WORK… plus rien ne s’affiche mais on peut vouloir y insérer des choses spécifiques.
OK, donc si je livre avec super-admin, la ressource SCRIPT changera de module et ce problème ne se posera plus (et donc plus besoin de livrer en tant que super-admin après cela)… Je comprends donc que ne ce n’est pas tout à fait “en dehors des clous” …
Je pense que je vais déplacer la ressource dans le module cible manuellement en tant que designer pour l’instant pour conserver la protection du système tant qu’on a pas terminé notre upgrade (on a eu d’autres cas qui ont pu être résolus en amont donc c’est utile de ne pas passer en force pour l’instant)…
Oui, il faut bien utiliser “responsive5” = pour la V5 et qui utilise derrière bootstrap4.
“responsive” est deprecated mais toujours supporté en 5.1, il hérite de Simplicité V4 (pour ceux qui voulaient rester en boostrap3 le temps de la transition de leur code Front). Les changements de classes CSS étaient trop importants, on avait du “forker” la disposition, et on devra peut être le refaire dans la prochaine version majeure (v6) car on va upgrader bootstrap (à priori plus rapide car en vanilla script).
Ok c’est clair… par contre je vais traiter cette dette plus tard car je ne vais pas pouvoir aborder ça de front avec le reste (donc je pars a priori sur responsive/bootstrap3 et je verrai pour switcher ultérieurement sur responsive5/bootstrap4).
Si vous utilisez les API UI Simplicité et pas du bootsrtap “en dur”, ce sera transparent, sinon faudra surement refactorer certaines choses, rien de compliqué mais chaque chose en son temps.
ps : je pense que si tu vas jeter un œil sur l’instance https://bcsidev.renault.simplicite.io tu verras probablement d’autres horreurs dans nos ~40 modules qui pourront poser d’autres problèmes… je sélectionne les combats d’aujourd’hui et je mets en attente ceux de demain )
)
)