Il serait intéressant d’uniformiser l’intégration de code externes, que ce soit des lib Java ou des lib JS. On pourrait aussi le renforcer, à date les mécanismes à disposition sont les suivants :
les librairies JS “simples” peuvent s’intégrer
en resource de la disposition en tant que script JS pour une utilisation globale. Il faut savoir que c’est à la disposition “default” qu’il faut l’ajouter, et la notion de disposition est peu intuitive
en resource de l’objet pour une utilisation
les librairies JS composées ou comprenant une hiérarchie de fichiers peuvent s’intégrer sous forme de fichier ZIP servi par un StaticSiteExternalObject
les librairies Java sans dépendances peuvent s’intégrer via un JAR dans SharedCode
les librairies Java plus complexes doivent s’intégrer avec les mécanismes maven dans une image Docker custom
faire une demande à la team Simplicité pour intégrer une autre librairie dans le socle Simplicité
Un point d’intégration unique “Librairies externes” serait-il intéressant à étudier?
ajout de librairies JS
intégrées dans le module, avec facilitations potentielles de téléchargement depuis URL / NPM
à partir d’une URL (CDN)
ajout de libraires Java
avec un mécanisme intégré de vérification de compatibilité
avec possibilité de téléchargement depuis maven-central
Bonus: cela permettrait notamment d’embarquer moins de librairies dans le socle et déléguer les intégrations et wrappers / Tools non indispensables au fonctionnement du socle à des modules de l’AppStore, réduisant la surface d’attaque de Simplicité.
Vaste sujet, on pourrait même changer l’OS du coup ?.
Effectivement la plateforme a ajouté des intégrations de composants tiers au fil du temps pour des besoins assez disjoints, donc pas centralisés et sans trop de limite. Il a beaucoup d’aspect à intégrer à ce besoin :
Dichotomie par construction :
Changer nativement les libs dans tomcat/lib ou la webapp => pb de build / custom docker
Ou les charger dynamiquement via le ClassLoader dynamique => lib paramétrable par un designer / livrée dans le module, pas besoin de redémarrer tomcat, rechargement à chaud
Dichotomie par fonction :
Les JAR : fonction back pour les utiliser des API métier
Les CSS/JS pour des composants front : globaux (UI), habilités (pour un scope) ou locaux (pour un objet ayant une fonction particulière)
La notion de SharedCode peut surement évoluer pour permettre plus de flexibilités et d’aide : compat maven / auto-update / CDN…
Dichotomie par architecture :
pb de compatibilité, d’intégration et de performances
ajouter des libs est-ce une erreur d’urbanisation de ses API ?
Simplicité n’est pas un tomcat, ni un wordpress, ni un IA… donc y intégrer des libs qui font tout autre chose sans qualification est très limite / voire à proscrire. Si on veut intégrer plus qu’une lib “utilitaire”, comme un site web ou un système tiers, c’est qu’on à surement rien compris à l’architecture d’un SI et à l’intégration. Il est beaucoup plus sage de créer un service “ailleurs” qui réalise une fonction trop complexe/risquée en terme d’intégration, et de l’appeler par API / chacun ses responsabilités / SLA…
Bref ajouter n’importe quoi touche à notre responsabilité contractuelle de livrer une plateforme low-code, et non pas un serveur d’applications ou de sites web.
La disposition est une notion historique “pre-responsive” qui servait à décrire le site par défaut et ses différentes variantes UI (theme et positionnements). Depuis qu’il n’y a plus que des “responsive” par version de bootstrap et les Themes, cette notion est peut être a redéfinir / simplifier en V6 en déportant les ressources JS ailleurs.
+1 pour AppStoriser des modules contenant le wrapper/tool + ses libs.externes.
Docusign, Stripe, Google…
Il y a un cas que j’ai oublié dans l’analyse, il faut parfois intégrer des libs “utilitaires” de versions/implémentations incompatibles avec le runtime, à date il y a 2 exemples gérés :
Driver JDBC pour connecter une base externe qui utilise un driver différent
Docusign : le client utilise une implémentation REST/JSON old-school incompatibles avec Simplicité
Il a fallu charger ces libs dans un class-loader à part et invoquer les méthodes par reflexion Java.
A voir si on généralise ce concept d’isolation via CL externe (comme une option des libs partagées).
L’avantage est de ne plus se soucier de la compatibilité avec les libs de sa version Tomcat/Simplicité
L’inconvénient est qu’il faut wrapper les appels via des invoke method (via un Tool static) pour ne jamais charger les classes externes dans le CL “officiel” de Simplicité qui surcharge la webapp et tomcat dynamiquement.
?.