Salut les gens,
j’espère que ce billet vous intéressera 
https://blog.spip.net/Composer.html
Amitiés,
Merci James, quel travail!
Si je comprends bien l'intérêt de Composer est de pouvoir plus
facilement "composer" et maintenir des distributions SPIP adaptées à des
besoins particuliers (SPIP standard pour revues en ligne, MediaSPIP pour
les vidéastes, SPIP-Seenthis pour les créateurs de communautés, etc.).
Ceci est le status quo .
L'intégration des normes proposées par le php-fig (donc sa compatibilité
avec Composer et d'autres outils php-fig) dans SPIP n'est pas pour
demain et fera partie d'un processus qui modifiera SPIP et reversera les
expériences faites avec notre dinosaure dans le développement de php-fig
à travers l'adhésion officielle au proupe de travail php-fig
(https://www.php-fig.org/personnel/)
Est-ce que je t'ai bien compris?
:-)k++
Salut Klaus,
C’est top, merci !
Et je pense qu'on a clairement tout à gagner à utiliser un outil standardisé et générique commun à tout l’ecosystème PHP comme Composer plutôt que de nous épuiser à développer et maintenir notre propre système
J'aimerais connaître aussi l'avis d'ESJ qui a beaucoup contribué à SPIP
dans le sens d'une "normalisation" de SPIP et de la syntaxe se son
langage de boucles. En même temps il est assez critique envers la
programmation objet qui d'après lui n'apporte pas grand chose par
rapport à un code bien structuré. ...
A suivre, quoi 
Amicalement,
klaus++
Hello tout le monde
J'aimerais connaître aussi l'avis d'ESJ qui a beaucoup contribué à SPIP
dans le sens d'une "normalisation" de SPIP et de la syntaxe se son
langage de boucles. En même temps il est assez critique envers la
programmation objet qui d'après lui n'apporte pas grand chose par
rapport à un code bien structuré. ...
Y aurait tellement à dire, que ça va être difficile de faire court.
Pour ce qui est de la programmation dite « objet »,
un des problèmes qu’elle entend résoudre est le nommage et la visibilité
des fonctions calculées, qu’elle appelle « méthode « et qu’elle organise
par des systèmes d’héritage sur lesquels personne n’est d’accord (cf entre autres les versions de PHP).
SPIP tourne autour du même sujet avec les fonctions surchargeables et les pipelines.
Faut-il les abandonner et se plier au modèlé dominant ? Sur le plan de la respectabilité sans doute,
sur le plan de l’efficacité du développement peut-être, mais ce n’est pas sûr.
Sur la question de la normalisaion du code, les méthodes sous-jacentes pour la mesure sont critiquables car trop limitées à de l’analyse syntaxique
(exemple typique: eval(X) serait une horreur, mais fwrite(X,f);include(f) rien à dire alors que ça fait la même chose).
Toutefois l’aspect respectabilité prend malheureusement de plus en plus d’importance
(c’est comme les agences de notation financières: méthodologie pas fiable, mais pouvoir de nuisance certain)
et il faut reconnaître que
1. pour des langages sans déclaration de type comme PHP et JS, des outils proches de ce que fournit un compilateur n’est pas du luxe;
2. les outils en question font quand même aujourd’hui un peu plus que de l’analyse syntaxique comme il y a 10 ans.
Au labo on a installé Sonarqube (https://www.sonarsource.com/) et c’est tout de même pas mal.
Un des avantages est qu’il n’est pas limité à un langage: on peut lui filer tout SPIP et il va dénoncer ce qui lui paraît suspect partout:
PHP, JS, CSS, XML (la déclaration de plugin) et HTML mais justement là il hurle à tort à cause de la syntaxe hors norme des squelettes.
Cela dit, et c’est aussi un autre de ses avantages, on peut éditer très finement les règles qu’il utilise pour ne plus voir
des messages qu’on sait non significatifs.
Cet aspect multi-langage me semble vraiment important dans le cas de SPIP, car la part de JS n’a cessé de grandir face à la part PHP,
et j’ai longtemps rêvé qu’on remplace le code PHP de SPIP par un module Apache, écrit dans n’importe quel langage, et ne traitant plus
que le trio JS/HTML/CSS. Composer, qui a démarré la discussion, est un outil de distribution intéressant et dont les liens avec PHP ne sont pas
déterminants en eux-mêmes (il aurait pu être écrit en autre chose si j’ai bien compris), ça me paraît un bon plan,
en revanche utiliser PHP-fig enverrait à mon avis une image de SPIP trop enracinée dans une unique langage et pour un gain que je ne vois pas
(ce la dit ma vue baisse). Mais il faut s’interroger sur l’avenir de PHP ? Perl, dont il est issu, est en train de mourir, qui sait s’il ne prendra pas le même chemin.
Mais ce n’est l’avis que d’un utilisateur de SPIP2.
esj
Hop,