Mettre un paquet.xml dans spip/prive

Équipes architecture
1

Le code des dossiers ecrire/ et prive/ sont très interdépendants et l’idée serait de poursuivre le découplage entre ces 2 composants.

Cela faciliterait notamment le chantier JS si spip/prive ne dépendait plus de code présent dans spip/ecrire.

Il y a un paquet.xml dans spip/dist, et bien sûr, il y en a un dans spip/ecrire. Bien qu’ls ne soient pas traités de la même manière que tout ceux qu’on pourrait trouver dans plugins/, plugins-dist/ (et optionnellement dans le dossier définit par la constante _DIR_PLUGINS_SUPPL), ils servent pour définir les menus, onglets, pipelines et certains procures (en particulier jquery, définit dans ecrire/pquet.xml, mais avec la lib livrée dans prive/ …)

Un paquet.xml dans prive/ apporterait à la fois, un peu de cohérence et ouvrirait la possibilité de déplacer du code PHP de ecrire vers prive (en particulier, la gestion de certains pipelines), permettant ainsi de réduire la nécessité de devoir faire des PR multiples dans plusieurs dépôts git.

J’ai fait un premier test, qui démontre la possibilité technique qui peut servir de point de départ. les MR seront chapeautées par ce ticket prive en tant que plugin (#115) · Issues · spip / prive · GitLab

5 « J'aime »
2

Oui, c’est une très bonne idée. Il faut continuer à faciliter le decouplage.

3

Il y a 124 déclarations de pipeline dans spip/ecrire/paquet.xml.

Elles pourraient désormais être réparties entre les descripteurs de ecrire, prive et dist.

Sauf erreur de ma part, les pipelines ci-dessous sont en doublon (parfois parce que 2 actions, mais pas toujours):

  • affichage_final
  • affiche_milieu
  • formulaire_admin
  • formulaire_fond
  • formulaire_traiter
  • header_prive_css
  • insert_head_css
  • pre_liens

J’ai cru comprendre que les balises <traduire ... /> étaient superflues désormais ? (J’ai peut-être mal compris)

Bref, il y a une opportunité pour procéder à quelques changements …

4

Qu’entend tu par « en doublons » ?

Et oui <traduire> est superflu. En pratique elle n’a jamais servi.

5

Il y a <pipeline nom="formulaire_admin" action="" /> 2 fois, par exemple

6

Ah oui ok, dans le paquet.xml.

Je dirais enlevons les doublons avec action vide, et gardons les doublons si 2 actions différentes ?

1 « J'aime »
7

Je viens de pousser un premier jet de redispatch des pipelines entre ecrire et prive.

Voir les commits suivants :

J’en ai profité pour traiter les dossiers d’installation (_DIR_PLUGINS, _DIR_PLUGINS_DIST, _DIR_RESTREINT, _ROOT_PLUGINS, _ROOT_PLUGINS_DIST, _ROOT_RESTREINT) sans les constantes historiques dans les fichiers de cache…

Il y a peut-être moyen de déplacer certains trucs dans spip/dist… en particulier ce qui concerne le frontent JS. À voir…

À voir aussi, les pipelines ici (que j’ai marqué unused) Draft: refactor: maquette prive-as-plugin (!159) · Requêtes de fusion · spip / ecrire · GitLab

ne semblent plus, sauf erreur, utilisés nulle part dans spip/*. Peut être qu’on pourrait les retirer ?

8

Merci @JamesRezo de te pencher sur ce chantier à la fois délicat et nécessaire (et que j’approuve).

Une réorganisation partielle du dépôt prive serait heureuse, en y incorporant les éléments issus de ecrire qui sont manifestement dédiés à l’espace privé ; mais l’on gagnerait aussi probablement (comme tu l’indiques) à déporter certaines fonctionnalités « hybrides » dans un dépôt dédié ; je parle de celles historiquement implémentées pour le privé mais qui ont connu un déploiement de facto côté public.
Bien souvent, il s’agit des fonctionnalités qui touchent au code côté navigateur (ou frontend).

Problématiques récentes abordées ici et là.

Déployer un dépôt par fonctionnalité aurait le mérite d’une organisation claire, mais s’avèrait probablement plus fastidieux niveau maintenance, ce qui contredit l’objectif du ticket initial.

Aussi, que pensez-vous de l’approche suivante :

  • Créer un nouveau dépot (dist) frontend avec une structure « meta »
frontend
 ├── jquery/
 ├── insert_head/
 ├── importmap/
 ├── ajaxCallback/
 ├── lib/ 
 ├── ...
 └── paquet.xml

Chaque dossier ciblant une fonctionnalité JS/Frontend (y compris le code php afférant) dont l’usage n’est pas exclusive à prive.

On pourrait obtenir une arborescence plus digeste au prix que quelques entrées supplémentaires dans la collection de _chemin() :

   <procure nom="jquery" />

   <chemin path="" />
   <chemin path="jquery" />
   <chemin path="insert_head" />
   <chemin path="importmap" />
   ...

Il semble pertinent d’y déplacer les libs JS (au moins les plus génériques (Sortable, bootstrap, … )

Il serait ainsi plus simple d’exfiltrer certaines fonctionnalités du core si leur codebase est déjà rassemblé sous un unique dossier ( :wave: jquery ).

  • La chaîne de dépendance serait la suivante :
    ecrire > frontend > prive
    mais aussi : ecrire > frontend > dist | plugin-x

Voyez-vous une limitation ou contre-indication en terme d’architecture ?
Chantier d’envergure, mais qui n’implique quasiment pas de rédaction de code… juste de la réorganisation et des tests.

Dernières remarques complémentaires :

  • avec une telle organisation, il est sans doute souhaitable (par soucis de cohérence) de renommer le module presentation.js en prive.js, puisqu’il resterait dans le dépot prive.
  • on peut ajouter ce ticket au ticket de roadmap
  • @JamesRezo a déjà épuré certaines constantes historiques du système de cache, qu’en est-il de _JAVASCRIPT et _DIR_JAVASCRIPT, utilisées (à mon corps défendant) dans importmap notamment ?
1 « J'aime »
9

Je vais regarder ça

Et pour commencer d’éventuelles expérimentations : spip / frontend · GitLab (que je vais ajouter aux PRs prive-as-plugin)

10

@placido je me faisais une réflexion similaire, mais je n’avais jamais reussi à vraiment la formuler. Je suis plutot favorable à l’évolution proposée.

Juste 2 points pour être sur d’avoir bien compris

  1. Dans ton explication de la chaine de dépendance > veut dire « fournit l’outil pour » et non pas « depend de » on est d’accord ?
  2. "On pourrait obtenir une arborescence plus digeste au prix que quelques entrées supplémentaires " par « plus digeste » c’est bien « par rapport à ce qui existe deja » et pas « par rapport à un autre element de mon message » ?
11

La commande ci-dessous permet d’installer un spip5 from scratch ciblé sur les branches du chantier prive-as-plugin

composer create-project --no-dev \
    --repository=https://get.spip.net/composer \
    --stability=dev --keep-vcs spip/spip </ou/tu/veux> dev-prive-as-plugin

Chaque plugin (et même prive, dist et ecrire ainsi que le dossier de base ) sont connectés aux branches git du chantier. Pour pousser des commits, il suffit d’aller dans chaque dossier impacté et utiliser git

Pour mettre à jour composer update suffit, car dans cette configuration, il fait tous les git pullnécessaires.

2 « J'aime »
12

Les constantes _JAVASCRIPT :

search _JAVASCRIPT

C’est utilisé dans 3 squelettes :

  • squelettes/escal
  • squelettes/spipcoop (plus de commit depuis 15 ans, pas un plugin)
  • squelettes/revue_ligne (plus de commit depuis 8 ans, pas un plugin)

2 plugins :

  • contrib/acs
  • contrib/crayons

Et uniquement dans deux composants spip/* :

  • prive
  • ecrire
  • dist

Donc, pas trop lourd à gérer si elles sont remplacées au profit d’autre chose ou dépréciées.

Il y a un truc qui m’enquiquine, c’est qu’elles sont exploitées dans le code à la fois comme un dossier de filesystem et comme une « route » d’url. J’aimerais bien distinguer les 2 usages en terme programmatique, ce qui impacterait spip-league/kernel en plus des dépôts actuels impactés par ce chantier, mais on peut faire plus simple provisoirement aussi.

13

Je viens de tester en PHP 8.2 & 8.3 et j’ai un enchaînement d’erreurs qui génère une 500 au final cf :

Got error 'PHP message: PHP Warning:  Undefined array key "necessite" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 507; PHP message: PHP Warning:  foreach() argument must be of type array|object, null given in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 507; PHP message: PHP Warning:  Undefined array key "utilise" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 520; PHP message: PHP Warning:  foreach() argument must be of type array|object, null given in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 520; PHP message: PHP Warning:  Undefined array key "necessite" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 507; PHP message: PHP Warning:  foreach() argument must be of type array|object, null given in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 507; PHP message: PHP Warning:  Undefined array key "utilise" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 520; PHP message: PHP Warning:  foreach() argument must be of type array|object, null given in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 520; PHP message: PHP Warning:  Undefined array key "prefix" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 916; PHP message: PHP Warning:  Undefined array key "chemin" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 924; PHP message: PHP Fatal error:  Uncaught Error: Undefined constant "_DIR_PRIVE" in /home/bb/sites/trunk/test/ecrire/inc/plugin.php:927
Stack trace:
#0 /home/bb/sites/trunk/test/ecrire/inc/plugin.php(927): constant()
#1 /home/bb/sites/trunk/test/ecrire/inc/plugin.php(865): plugins_precompile_chemin()
#2 /home/bb/sites/trunk/test/ecrire/inc/plugin.php(750): ecrire_plugin_actifs()
#3 /home/bb/sites/trunk/test/ecrire/inc_version.php(121): actualise_plugins_actifs()
#4 /home/bb/sites/trunk/test/spip.php(17): include_once('...')
#5 /home/bb/sites/trunk/test/index.php(4): include('...')
#6 {main}
  thrown in /home/bb/sites/trunk/test/ecrire/inc/plugin.php on line 927
14

flûte, je regade ça …

15

huhu … :clown_face: c’est corriged

1 « J'aime »
16

Nouveau problème avec les pipelines déplacés dans le repo prive, on en cause directement dans les PRs sur git.spip :wink:

17

Hello

Pour l’utilisation dans Escal, oubliez. C’est un vieux fichier que j’ai oublié de supprimer, ce qui sera fait dans la prochaine version.

1 « J'aime »
18

Il y a 2 fichiers en fait. orr.html et agenda.html. Quoiqu’il arrive, tu seras prévenu quand la solution sera pérennisée (sachant qu’il est fort probable que les constantes soit dépréciées en 5.x et ne seront supprimées qu’en 6.x, tu as quelques années devant toi :wink: )

19

Yep

20

J’ai fait un truc rapide qui déprécie les constantes au profit de 2 nouveaux paramètres du kernel (feat: spip.frontend.js_subdir parameter (!10) · Requêtes de fusion · spip-league / kernel · GitLab) pilotés par le fichier config/spip/frontend.php (refactor: maquette prive-as-plugin (!4899) · Requêtes de fusion · spip / dist · GitLab)

Pour le tester soit la commande composer create_project explicitée plus haut, soit composer update si vous avez déjà testé

Si ça passe, il sera possible de déplacer ecrire/inc/importmap.php dans le plugin frontend (ainsi que la déclaration de son pipeline et son Test Unitaire)

Merci d’avance pour vos retours :slight_smile: