[SPIP Zone] [ALBUMS] Quellques modifications à venir

[placido]

Bonjour,

J'aimerai effectuer quelques évolutions sur le plugin alors j'annonce la
couleur.

1) Se débarasser des constantes de personnalisation - define() - au
profit d'une configuration stockée dans spip_meta, bien plus souple.
(Mais le processus de mise à jour prendra en compte ces valeurs si elles
existent.)

2) En conséquence une reprise du formulaire configurer_albums. SAISIES
étant déjà en dépendance, je compte m'appuyer alègrement dessus pour
simplifier la chose.

3) Une reprise a minima des modèles pour transposer les #EVAL{} en #CONFIG{}

- Des remarques ? J'ai lu le TODO, mais la plupart des éléments semblant
déjà réalisés, j'en conclu qu'il n'est pas tout à fait à jour.

++

[maieul (Maïeul Rouquette)]

Le 28/02/2018 à 05:01, placido a écrit :

Bonjour,

J'aimerai effectuer quelques évolutions sur le plugin alors j'annonce la
couleur.

1) Se débarasser des constantes de personnalisation - define() - au
profit d'une configuration stockée dans spip_meta, bien plus souple.
(Mais le processus de mise à jour prendra en compte ces valeurs si elles
existent.)

2) En conséquence une reprise du formulaire configurer_albums. SAISIES
étant déjà en dépendance, je compte m'appuyer alègrement dessus pour
simplifier la chose.

3) Une reprise a minima des modèles pour transposer les #EVAL{} en #CONFIG{}

- Des remarques ? J'ai lu le TODO, mais la plupart des éléments semblant
déjà réalisés, j'en conclu qu'il n'est pas tout à fait à jour.

++

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

je suis dubitatif. Pour ma part je considère que les Constantes de personnalisation sont souvent plus simples que les config lorsqu'on doit déployer un squelette utilisant massivement un plugin, et pour laquelle on ne veut pas laisser de marge de manœuvre. C'est pourquoi j'aurais tendance à préférer un système qui dise
1. Priorité à la constante
2. Si pas de constante, config

C'est ce que j'utilise par exemple pour menu_accordeon.

En fait il manque dans SPIP un mécaniosme générique du type #CONSTANTE_SINON_CONFIG, qui permettrait de faire tenir ensemble les tenants des deux écoles.

[tcharlss]

Salut placido,

Le 28/02/2018 à 05:01, placido a écrit :

1) Se débarasser des constantes de personnalisation - define() - au
profit d'une configuration stockée dans spip_meta, bien plus souple.
(Mais le processus de mise à jour prendra en compte ces valeurs si elles
existent.)

Si les constantes posent problème, ok pour trouver une meilleure solution.
Par contre je n'ai pas l'impression que le fait de les passer en config règle la question.
Quand je les avais ajoutées, c'était surtout dans le but de permettre à des *plugins* de les surcharger : on active un plugin de squelettes, et pouf, ça change l'affichage des albums automatiquement selon les besoins du squelette, et non pas des admins.
Pour moi c'est un besoin différent que les formulaires de configuration. Après, il y a peut-être des alternatives, les autres plugins pourraient changer la config d'albums à l'installation, pourquoi pas. Mais ça me semble moins simple.

Et puis ça va casser la compatibilité pour les plugins ou les gens qui utilisent déjà ces constantes dans leur options, comment gérer ça ?

Après, avec le recul je commence à douter de la pertinence de toutes ces options. Surtout que la majorité peuvent se gérer directement dans les CSS. Si je m'écoutais j'en virerais la moitié

2) En conséquence une reprise du formulaire configurer_albums. SAISIES
étant déjà en dépendance, je compte m'appuyer alègrement dessus pour
simplifier la chose.

C'est une erreur de ma part, saisies n'est pas nécessaire (c'était le cas au début, puis j'ai viré la dépendance après). D'ailleurs les 3 <necessite> peuvent être enlevés , c'était un contresens de ma part à l'époque (on ne surcharge rien de ces plugins).

3) Une reprise a minima des modèles pour transposer les #EVAL{} en #CONFIG{}

Cf. ma réponse au 1.

[maieul (Maïeul Rouquette)]

Le 28/02/2018 à 14:52, Maïeul a écrit :

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

je suis dubitatif. Pour ma part je considère que les Constantes de personnalisation sont souvent plus simples que les config lorsqu'on doit déployer un squelette utilisant massivement un plugin, et pour laquelle on ne veut pas laisser de marge de manœuvre. C'est pourquoi j'aurais tendance à préférer un système qui dise
1. Priorité à la constante
2. Si pas de constante, config

C'est ce que j'utilise par exemple pour menu_accordeon.

En fait il manque dans SPIP un mécaniosme générique du type #CONSTANTE_SINON_CONFIG, qui permettrait de faire tenir ensemble les tenants des deux écoles.
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

J'ai ouvert un ticket, c'est une réflexion que je me fais depuis longtemps.

Constante ou config ? (#4105) · Tickets · spip / spip · GitLab

[tcharlss]

Le 28/02/2018 à 14:52, Maïeul a écrit :

je suis dubitatif. Pour ma part je considère que les Constantes de personnalisation sont souvent plus simples que les config lorsqu'on doit déployer un squelette utilisant massivement un plugin, et pour laquelle on ne veut pas laisser de marge de manœuvre.

Ah voilà Maïeul, c'est exactement ce que je voulais dire en mieux dit

Donc je ne suis pas chaud pour cette modif tant qu'on a pas trouvé une solution qui conserve ce principe.

[placido]

Le 28/02/2018 à 10:52, Maïeul a écrit :

je suis dubitatif. Pour ma part je considère que les Constantes de
personnalisation sont souvent plus simples que les config lorsqu'on doit
déployer un squelette utilisant massivement un plugin, et pour laquelle
on ne veut pas laisser de marge de manœuvre. C'est pourquoi j'aurais
tendance à préférer un système qui dise
1. Priorité à la constante
2. Si pas de constante, config

Pour ma part, je reste opposé à l'usage de constantes pour des éléments
de personnalisation (susceptibles de changer).
C'est très vite la plaie à gérer lorsque cela concerne des préférences
que l'on voudrait modifier ou compléter dans des sous-plugins. Et le
principe de surcharge du SPIP ne sait pas gérer l'ordre de définition
des constantes de manière robuste.

Plus de détails sur ce ticket notamment :

Ordre des inclures dans cache/charger_plugins_options.php (#4102) · Tickets ·...

L'usage de constantes devrait se limiter à celui d'un alias.

On a déjà quasiment tout pour gérer la configuration de manière efficace
et extensible grâce à inc/config + ordre de surcharge + pipelines. La
coexistante constantes / config-meta est le fruit d'une mutation en
cours, mais vouloir les faire coexister durablement me semble fastidieux
et inutilement ambigu.

Aussi, chaque occasion de migrer proprement les choses devrait être
considérée comme opportune.

Pour en revenir au plugin Albums, as tu une connaissance de
développement du plugin ? Sais-tu si toutes les constantes sont
utilisées ou certaines sont considérées obsolètes ?

Merci

[maieul (Maïeul Rouquette)]

Le 28/02/2018 à 15:51, placido a écrit :

Le 28/02/2018 à 10:52, Maïeul a écrit :

je suis dubitatif. Pour ma part je considère que les Constantes de
personnalisation sont souvent plus simples que les config lorsqu'on doit
déployer un squelette utilisant massivement un plugin, et pour laquelle
on ne veut pas laisser de marge de manœuvre. C'est pourquoi j'aurais
tendance à préférer un système qui dise
1. Priorité à la constante
2. Si pas de constante, config

Pour ma part, je reste opposé à l'usage de constantes pour des éléments
de personnalisation (susceptibles de changer).
C'est très vite la plaie à gérer lorsque cela concerne des préférences
que l'on voudrait modifier ou compléter dans des sous-plugins. Et le
principe de surcharge du SPIP ne sait pas gérer l'ordre de définition
des constantes de manière robuste.

Plus de détails sur ce ticket notamment :
Ordre des inclures dans cache/charger_plugins_options.php (#4102) · Tickets · spip / spip · GitLab

L'usage de constantes devrait se limiter à celui d'un alias.

On a déjà quasiment tout pour gérer la configuration de manière efficace
et extensible grâce à inc/config + ordre de surcharge + pipelines. La
coexistante constantes / config-meta est le fruit d'une mutation en
cours, mais vouloir les faire coexister durablement me semble fastidieux
et inutilement ambigu.

Aussi, chaque occasion de migrer proprement les choses devrait être
considérée comme opportune.

perso, je suis opposé aux formulaires de cofnig pour ce qui relève des réglages d'affichage de squelettes, sauf exception ;-).

Cela étant ta remarque est fondée, mais je pense pas que passer en config soit la bonne solution.

Pour en revenir au plugin Albums, as tu une connaissance de
développement du plugin ? Sais-tu si toutes les constantes sont
utilisées ou certaines sont considérées obsolètes ?

Merci

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

[J-C (Jean-Christophe)]

Le 28/02/2018 à 16:06, Maïeul a écrit :

perso, je suis opposé aux formulaires de cofnig pour ce qui relève des réglages d'affichage de squelettes, sauf exception ;-).

Euh là je ne comprends pas : comment régler l'affichage d'un plugin sans formulaire de config ?

[placido]

Le 28/02/2018 à 10:56, Charles Razack a écrit :

Et puis ça va casser la compatibilité pour les plugins ou les gens qui
utilisent déjà ces constantes dans leur options, comment gérer ça ?

Je compte faire ainsi :

Une fonction album_config_defaut() qui renvoit un tableau des
préférences par défaut en vérifiant la présence des constantes
éventuelles déclarées.

Lors de l'installation ou de la migration en 3.6.0 (par exemple) on
fusionne ce tableau avec la config d'albums existante et on remet le
tout dans la méta albums.

La valeur de la constante est bien prise en compte au moment de la
migration donc. Au delà, en effet, c'est seulement le formulaire de
configuration qui prime (mais ce dernier, basé sur saisies est
accessibles aux sous-plugins).

[maieul (Maïeul Rouquette)]

Le 28/02/2018 à 16:11, Jean-Christophe Villeneuve a écrit :

Le 28/02/2018 à 16:06, Maïeul a écrit :

perso, je suis opposé aux formulaires de cofnig pour ce qui relève des réglages d'affichage de squelettes, sauf exception ;-).

Euh là je ne comprends pas : comment régler l'affichage d'un plugin sans formulaire de config ?
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

par une constante c'est possible, ca se fait pour certains plugins, c'est juste un choix du / de la dev. Et c'est tout le débat actuel

[J-C (Jean-Christophe)]

Le 28/02/2018 à 16:26, Maïeul a écrit :

Le 28/02/2018 à 16:11, Jean-Christophe Villeneuve a écrit :

Le 28/02/2018 à 16:06, Maïeul a écrit :

perso, je suis opposé aux formulaires de cofnig pour ce qui relève des réglages d'affichage de squelettes, sauf exception ;-).

Euh là je ne comprends pas : comment régler l'affichage d'un plugin sans formulaire de config ?

par une constante c'est possible, ca se fait pour certains plugins, c'est juste un choix du / de la dev. Et c'est tout le débat actuel

Et si tu es contre ces formulaires, tu voudrais qu'un plugin comme Escal soit paramétré par des constantes ?
Ou alors ça fait partie des exceptions ?

[tcharlss]

Le 28/02/2018 à 16:11, placido a écrit :

Je compte faire ainsi :
Une fonction album_config_defaut() qui renvoit un tableau des
préférences par défaut en vérifiant la présence des constantes
éventuelles déclarées.

Lors de l'installation ou de la migration en 3.6.0 (par exemple) on
fusionne ce tableau avec la config d'albums existante et on remet le
tout dans la méta albums.

La valeur de la constante est bien prise en compte au moment de la
migration donc. Au delà, en effet, c'est seulement le formulaire de
configuration qui prime (mais ce dernier, basé sur saisies est
accessibles aux sous-plugins).

Ok je vois le principe, ça pourrait le faire techniquement.

Ce qui me pose problème c'est quand même le fait d'exposer ces options dans le formulaire de configuration.
D'une part je suis d'avis de le garder le plus simple possible, et surtout ce n'était pas l'intention de départ de donner la main aux admins là-dessus.

Je ferais la liste des constantes que je considère superflues quand j'aurais le temps.

En parlant d'une éventuelle 3.6, on pourrait combiner ça avec d'autres modifs que j'ai en cours pour finir l'intégration avec SPIP 3.2 (en attente depuis les calendes grecques).

[maieul (Maïeul Rouquette)]

Le 28/02/2018 à 16:37, Jean-Christophe Villeneuve a écrit :

Le 28/02/2018 à 16:26, Maïeul a écrit :

Le 28/02/2018 à 16:11, Jean-Christophe Villeneuve a écrit :

Le 28/02/2018 à 16:06, Maïeul a écrit :

perso, je suis opposé aux formulaires de cofnig pour ce qui relève des réglages d'affichage de squelettes, sauf exception ;-).

Euh là je ne comprends pas : comment régler l'affichage d'un plugin sans formulaire de config ?

par une constante c'est possible, ca se fait pour certains plugins, c'est juste un choix du / de la dev. Et c'est tout le débat actuel

Et si tu es contre ces formulaires, tu voudrais qu'un plugin comme Escal soit paramétré par des constantes ?
Ou alors ça fait partie des exceptions ?

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Escal étant lui même un squelette, je pense que le formulaire a du sens.

Mais bon, si tu regarde les tickets, tu verra qu'il y a des gros débat.

[Mist_GraphX]

Le 28/02/2018 à 17:50, Maïeul a écrit :

Le 28/02/2018 à 16:37, Jean-Christophe Villeneuve a écrit :

Le 28/02/2018 à 16:26, Maïeul a écrit :

Le 28/02/2018 à 16:11, Jean-Christophe Villeneuve a écrit :

Le 28/02/2018 à 16:06, Maïeul a écrit :

perso, je suis opposé aux formulaires de cofnig pour ce qui relève des réglages d'affichage de squelettes, sauf exception ;-).

Euh là je ne comprends pas : comment régler l'affichage d'un plugin sans formulaire de config ?

par une constante c'est possible, ca se fait pour certains plugins, c'est juste un choix du / de la dev. Et c'est tout le débat actuel

Et si tu es contre ces formulaires, tu voudrais qu'un plugin comme Escal soit paramétré par des constantes ?
Ou alors ça fait partie des exceptions ?

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Escal étant lui même un squelette, je pense que le formulaire a du sens.

Mais bon, si tu regarde les tickets, tu verra qu'il y a des gros débat.

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Hello,

je suis pareil pas pour les formulaires de configs car quand on a 60 plugin d'installés on oublie toujours un truc , même en utilisant un exporteur de config , y a toujours un risque.

sur certains plugins , je passe/gère toute la config avec une pipeline et un array, et je modifie si besoin depuis mon theme/skel …

je sais pas si c'est une bonne méthode mais moi je trouve ça plus simple dans mes cas d'utilisation.

--
Bonne journée
Arnaud B. (Mist. GraphX)

[JLuc]

Un truc qu'il faut configurer par constantes convient bien à des informaticiens.

Lorsqu'un plugin peut s'installer et s'utiliser sans faire de dev php
ni écrire ou modifier de squelette HTML, ni de css,
ce serait très+ dommage de ne pas pouvoir le configurer par un formulaire.

Et moins un plugin nécessite de compétences de dev et d'édition de code,
plus la configuration par formulaire est préférable.

Faut voir comment Album se situe dans cette graduation...
JL

[rastapopoulos]

À mon avis vous prenez le problème à l'envers, ce n'est pas quelle
méthode de config *le dev* aime et ensuite on dit que cette méthode
plait à tel public. C'est exactement l'inverse qu'il faut faire, mais
pas du tout en regardant si ça plait ou pas.

Pour chaque config, on doit se demander à qui elle est *destinée*, et du
coup ensuite voir comment elle doit être définie.

Toute config n'a pas à être dans un form de config, pas du tout (et
d'ailleurs dès le début du fil de Placido ya une confusion entre
comparer constante et form de config, alors qu'on doit comparer
constante et infos en metas, ce qui n'a rien à voir : une meta ne vient
pas obligatoirement d'un form de config, interface humaine).

Cela dépend de son utilité, et de nombreuses configs sont entièrement
destinées aux intégrateurices de squelettes qui doivent dire alors "MON
jeu de squelette utilise obligatoirement cette fonctionnalité et donc
doit l'activer de manière certaine, permanente, pérenne" et donc *sans*
qu'on puisse la désactiver si quelqu'un retouche à un form de config !

Les configs avec interface humaine ne doivent l'être que… bah pour des
config qui peuvent être changées en permanence et qui sont bien prises
en compte quelque soit le squelette, donc des choses que les
utilisateurs finaux non informaticien⋅nes (ni dev, ni intégration)
peuvent activer/désactiver en permanence sans rien casser.

À part ça je suis d'accord depuis le début avec Placido que les
constantes c'est vraiment pas mal de la merde et qu'on devrait tendre
vers leur extinction, sauf cas rare. Mais je ne suis pas d'accord avec
l'utilisation uniquement des metas *en base* car elles peuvent être
changés n'importe quand par d'autres, donc pour le déploiement *sûr et
pérenne* c'est n'importe quoi aussi.

J'ai expliqué tout ça dans le ticket de Maieul et j'ai proposé une
solution à priori toute conne, qui ne casse rien chez personne, et même
qui va faire que les intégrateurices n'auront à peu près rien à toucher :
https://core.spip.net/issues/4105#note-4

(On a trois fils de discussion à la fois pour parler des configs, c'est
assez embêtant, 2 tickets, et là en emails… pas facile à suivre et ne
pas se répéter.)

--
RastaPopoulos

[placido]

Le 28/02/2018 à 12:49, Charles Razack a écrit :

D'une part je suis d'avis de le garder le plus simple possible,

J'approuve. Voilà un aperçu de que ça donnerait en reprenant tel quel
les toutes options actuelles (avec des fieldsets pliables) :

https://pic.infini.fr/enbcR3RL/pphXV97V.png

surtout ce n'était pas l'intention de départ de donner la main aux
admins là-dessus.

Soit, mais ce qui est configurable via constante n'a pas moins de
légitimité à l'être via un formulaire, dans la mesure l'admin est le même.

Note que ce qui m'interesse n'est pas tant de disposer d'un formulaire à
ralonge pour ces reglages, mais de pouvoir intervenir sur cette config
dans le cadre d'un sous-plugin.

C'est la question du moment (Constante ou config ? (#4105) · Tickets · spip / spip · GitLab) et ça
rentre dans le cadre d'un debat plus large.

Du coup, je vais surement attendre et garder mes modifications du
passage constantes -> config dans mon stash (sauf si vous trouvez ça
déjà utile), en espérant qu'une solution emportant l'adhésion émerge.
Patience et longueur de temps valent mieux...

Je ferais la liste des constantes que je considère superflues quand
j'aurais le temps.

merci, ça peut aider.

En parlant d'une éventuelle 3.6, on pourrait combiner ça avec d'autres
modifs que j'ai en cours pour finir l'intégration avec SPIP 3.2 (en
attente depuis les calendes grecques).

J'ai quelques suggestions sur le sujet. Où peut-on en parler ? Sur la
liste ou plutôt là -> Connexion · GitLab ?

[rastapopoulos]

Le 01/03/2018 à 16:17, placido a écrit :

Soit, mais ce qui est configurable via constante n'a pas moins de
légitimité à l'être via un formulaire, dans la mesure l'admin est le même.

Pas d'accord, ce que je disais dans mon email précédent.

Ce qui compte c'est justement de définir à qui est réellement destiné
une configuration, et non ce n'est pas forcément aux admins non
informaticien⋅nes.

Certaines configurations sont utiles quelques soit le site, quelque soit
le squelette publique, et dans ce cas ça peut être donné à configurer
dans une interface humaine.
Par exemple la taille des images générées, ça peut être donné à configurer.

D'autres configurations sont des trucs techniques destinés uniquement
aux intégrateurices, et ces choix sont à faire par celleux qui
nécessitent ou utilisent le plugin dans leur code.
Par exemple quelle balise HTML est utilisée pour ci ou ça, c'est pas aux
admins éditoriaux de décider ça.
Tout comme choisir si le site public est en HTML5 ou pas (ça j'ai dit
plusieurs fois et dans un ticket que ça devrait être un choix de
non-dev, c'est le squelette qui doit le déclarer).

Donc ya pas d'automatisme tout comme ceci ou tout comme cela. Certaines
configs doivent être par interface, d'autres uniquement en code.

Note que ce qui m'interesse n'est pas tant de disposer d'un formulaire à
ralonge pour ces reglages, mais de pouvoir intervenir sur cette config
dans le cadre d'un sous-plugin.

C'est donc justement un cas où c'est pour déployer, donc en code, pas
par interface.

(Ce qui n'empêche que des configs par interface, stockées en base,
devraient aussi pouvoir être surchargée-forcée en code si on veut
déployer une utilisation avec une valeur attendue précise.)

--
RastaPopoulos

[tcharlss]

Le 01/03/2018 à 16:17, placido a écrit :

J'approuve. Voilà un aperçu de que ça donnerait en reprenant tel quel
les toutes options actuelles (avec des fieldsets pliables) :

https://pic.infini.fr/enbcR3RL/pphXV97V.png

Merci pour la capture, ça donne une bonne idée de la chose.
Je pense que toutes les options qui peuvent être réglées en CSS n'ont pas leur place dans ce formulaire (pour l'instant certaines modifient effectivement le HTML produit, mais dans la prochaine évolution ce sera simplement des classes ajoutées).

- Affichage de la légende
- Position de la légende
- Choix des types de métas pour la vue en liste

Et également :

- Type de balise pour le titre : c'était pour permettre aux squelettes de respecter la hiérarchie des titres, et c'est donc aux squelettes de définir ça, pas aux admins.

Pour résumer, ça ne laisserait que le traitement des images et la pagination.

J'ai quelques suggestions sur le sujet. Où peut-on en parler ? Sur la
liste ou plutôt là -> Connexion · GitLab ?

Sur la liste ça aura plus de lisibilité, mais après pour le suivi tâches à réaliser et cie, c'est quand même plus pratique d'utiliser un outil fait pour ça.
Donc plutôt ouvrir un ticket sur git.spip.net je dirais, "évolutions pour spip 3.2" ou un truc du genre.

[tcharlss]

Sur la liste ça aura plus de lisibilité, mais après pour le suivi tâches à réaliser et cie, c'est quand même plus pratique d'utiliser un outil fait pour ça.
Donc plutôt ouvrir un ticket sur git.spip.net je dirais, "évolutions pour spip 3.2" ou un truc du genre.

Ah voilà, j'avais commencé à créer des tickets pour SPIP 3.2 : Connexion · GitLab
Tu peux ouvrir un nouveau ticket pour la config / le formulaire.

Il faudrait créer un tag SPIP 3.2 mais pour l'instant on ne peut pas en créer.