[spip-dev] Remarques sur les extensions/plugins de la 2.1

eric_tonton · Mars 1, 2010, 1:12

Hello,

Je profite de la 2.1 en cours de tests pour faire ou refaire quelques remarques sur la gestion des « extensions/plugins ».

Notions et appellations

C’est un débat qu’on a déjà eu quand on parlait de thème, squelettes et « plugins ou modules fonctionnels ».
Le plugin, amha, est un moyen/mécanisme de distribution d’une extension. SPIP propose trois types d’extensions:

le module fonctionnel ou fonction comme crayons qui, aujourd’hui, possède enfin une catégorie (maintenance, statistique, édition…)
le squelette comme ZPIP
et le thème comme ceux de ZPIP, par exemple Arclite.

Je serais donc d’avis de regrouper cette notion sous le vocable « extensions » et donc d’abandonner le termes « extensions » utilisé par le core pour ses fonctions complémentaires.
Pour ces dernières on pourrait les appeler « Modules SPIP complémentaires » ou « Fonctions SPIP complémentaires ».

Installation

En suivant le point 1), il serait assez logique d’installer:

les extensions fonctionnelles, thèmes et squelettes dans un dossier extensions/ plutôt que plugins/. Cependant, cela introduisant un gros changement, les mettre déjà dans plugins/ serait déjà pas mal car on y gagnerait en lisibilité et on supprimerait le dossier themes/.
les modules SPIP complémentaires dans un dossier modules/ plutôt que extensions/.

Interface privée

Je serais d’avis de plus séparer la gestion des diverses extensions y compris celles du core. C’est assez logique si on considère que le plugin est un mécanisme et non une finalité. Donc on pourrait séparer les interfaces en fonction des extensions:

Pour les modules SPIP complémentaires, plutôt que d’afficher la liste dans la page des « plugins actifs », on pourrait afficher cette même liste soit comme un bloc supplémentaire de la page de configuration « Fonctions avancées », soit comme un onglet supplémentaire du menu Configuration.
Pour ce qu’on appelle aujourd’hui les plugins et qu’on pourrait appeler dès lors extensions la 2.1 propose déjà trois onglets dans la page de gestion des plugins. Toutes ces pages ne font aucune distinction entre les squelettes, les thèmes et les extensions fonctionnelles ce qui est parfois confus.
On peut imaginer:

a) Pour chaque page, en utilisant la catégorie, on scinde la liste de chaque onglets en 3 listes: squelettes, thèmes, fonctions
b) Pour les thèmes, passer Zen garden en modules SPIP complémentaires. Je trouve que choisir des thèmes sans Zen Garden a peu d’intérêt.

Ou alors séparer les pages de gestion des squelettes, thèmes et fonctions… ???

Coté interface, étant donné qu’on peut agir de la même façon sur les plugins de l’onglet « Plugins actifs » et « Liste des plugins » je comprends pas l’intérêt de ces deux onglets. La liste des plugins actifs ne devrait pas posséder de bouton d’action non (donc plus besoin de coche) ? Tout se faisant via la liste des plugins installés… A creuser…

Coté libellé, Plugins actifs (ou Extensions actives) est ok mais Plugins (ou Extensions) installés serait plus compréhensible que « Liste des plugins ».
Désinstaller est pas très explicite car il n’est pas le pendant d’installer car l’installation physique du plugin ne lance pas la création des tables spécifiques si c’est le cas.

Voilà pour l’instant

b_b · Mars 1, 2010, 8:23

Salut,

Le plugin, amha, est un moyen/mécanisme de distribution d'une extension.
SPIP propose trois types d'extensions:
- le module fonctionnel ou fonction comme crayons qui, aujourd'hui,
possède enfin une catégorie (maintenance, statistique, édition...)
- le squelette comme ZPIP
- et le thème comme ceux de ZPIP, par exemple Arclite.

Je serais donc d'avis de regrouper cette notion sous le vocable
"extensions" et donc d'abandonner le termes "extensions" utilisé par le
core pour ses fonctions complémentaires.

Pourquoi pas, mais ça implique de bien communiquer sur ce changement de nom plugins => extensions. On va encore dire que ça change tout le temps chez SPIP

Pour ces dernières on pourrait les appeler "Modules SPIP
complémentaires" ou "Fonctions SPIP complémentaires".

"Modules" tout court c'est plus simple non ?

1) Installation

En suivant le point 1), il serait assez logique d'installer:
- les extensions fonctionnelles, thèmes et squelettes dans un dossier
extensions/ plutôt que plugins/. Cependant, cela introduisant un gros
changement, les mettre déjà dans plugins/ serait déjà pas mal car on y
gagnerait en lisibilité et on supprimerait le dossier themes/.

Changer de nom au dossier /plugins n'est peut être pas une bonne idée mais, si on souhaite être cohérent avec le changement d'appellation que tu proposes il faudrait le faire bien sûr.

- les modules SPIP complémentaires dans un dossier modules/ plutôt que
extensions/.

D'accord.

1) Interface privée

Je serais d'avis de plus séparer la gestion des diverses extensions y
compris celles du core. C'est assez logique si on considère que le
plugin est un mécanisme et non une finalité. Donc on pourrait séparer
les interfaces en fonction des extensions:

- Pour les modules SPIP complémentaires, plutôt que d'afficher la liste
dans la page des "plugins actifs", on pourrait afficher cette même liste
soit comme un bloc supplémentaire de la page de configuration "Fonctions
avancées", soit comme un onglet supplémentaire du menu Configuration.

Je ne vois pas l'intérêt de coller cette liste dans une page de configuration alors qu'on ne peut pas configurer ni désactiver ces modules.

- Pour ce qu'on appelle aujourd'hui les plugins et qu'on pourrait
appeler dès lors extensions la 2.1 propose déjà trois onglets dans la
page de gestion des plugins. Toutes ces pages ne font aucune distinction
entre les squelettes, les thèmes et les extensions fonctionnelles ce qui
est parfois confus.
On peut imaginer:

a) Pour chaque page, en utilisant la catégorie, on scinde la liste de
chaque onglets en 3 listes: squelettes, thèmes, fonctions

Oui pourquoi pas.

b) Pour les thèmes, passer Zen garden en modules SPIP complémentaires.
Je trouve que choisir des thèmes sans Zen Garden a peu d'intérêt.

Oui aussi, mais je pense que Cedric va nous dire qu'il faut qu'on attende que tout ça soit stabilisé (les specs de Z ne sont pas encore publiées et il reste des choses à voir du coté de la compatibilité des thèmes avec les squelettes Z autres que Zpip). À mon avis, c'est une chose qu'il faudra reporter pour la sortie d'une distribution SPIP + zpip + themes ou la version 2.2 de SPIP.

Ou alors séparer les pages de gestion des squelettes, thèmes et
fonctions.... ???

Bof

Coté interface, étant donné qu'on peut agir de la même façon sur les
plugins de l'onglet "Plugins actifs" et "Liste des plugins" je comprends
pas l'intérêt de ces deux onglets.

Ouep cette présentation "sur deux pages" m'a un peu déstabilisé au début. De plus je trouve embêtant d'arriver sur une simple liste qui ne me permet pas d'activer un plugin directement. Deux clics au lieu d'un avant.

La liste des plugins actifs ne
devrait pas posséder de bouton d'action non (donc plus besoin de coche)
? Tout se faisant via la liste des plugins installés... A creuser...

Coté libellé, Plugins actifs (ou Extensions actives) est ok mais Plugins
(ou Extensions) installés serait plus compréhensible que "Liste des
plugins".

D'accord, peut être même "disponibles" plutôt que "installés". Sinon on risque de provoquer de la confusion entre les différents états installés/activés.

Pat2 · Mars 1, 2010, 11:57

On avait déjà le dossier plugins/auto, pourquoi pas un dossier plugins/extensions, plugins/actifs ou même plugins/actifs_totalement_indesactivables ?

Pat

davux · Mars 2, 2010, 5:59

Mon, 01 Mar 2010 21:23:34 +0100, Bruno:

> a) Pour chaque page, en utilisant la catégorie, on scinde la liste
> de chaque onglets en 3 listes: squelettes, thèmes, fonctions

Oui pourquoi pas.

Cette réflexion sur l'ergonomie est très bonne, mais elle pourrait
être généralisée ; le fait qu'elle s'applique spécialement aux thèmes
Zpip me pose question. Aujourd'hui c'est Zpip avec ses thèmes, demain
ça peut être une autre application des plugins différente des autres,
et de fait il y en a déjà plusieurs: méthodes d'authentification par
exemple. Le système de plugins a été justement conçu pour être
générique.
À côté de ça, une notion de catégorie a récemment été introduite et
permet de grouper ces plugins par familles, de façon souple et
réactive, sans devoir repenser le code de SPIP à chaque apparition
d'une nouvelle famille.

Du coup, est-ce que ça ne ferait pas sens de continuer à considérer les
thèmes Zpip comme des plugins, car c'est ce qu'ils sont techniquement,
et simplement les grouper dans une catégorie "thèmes du site public" ou
"thèmes Zpip", "thèmes", ou nom équivalent ?

Ensuite, dans l'interface (et pourquoi pas dans la hiérarchie des
dossiers, si les plugins deviennent nombreux), la séparation peut se
faire suivant ces catégories, en se fendant même d'une petite icône pour
chacune, si on veut. De cette manière les thèmes seront effectivement
séparés du reste, mais par un processus plus générique.

eric_tonton · Mars 2, 2010, 7:52

Yo,

Mon, 01 Mar 2010 21:23:34 +0100, Bruno:

a) Pour chaque page, en utilisant la catégorie, on scinde la liste
de chaque onglets en 3 listes: squelettes, thèmes, fonctions

Oui pourquoi pas.

Cette réflexion sur l'ergonomie est très bonne, mais elle pourrait
être généralisée ; le fait qu'elle s'applique spécialement aux thèmes
Zpip me pose question.

Oups, je me suis pas du tout limité aux thèmes ZPIP !

Aujourd'hui c'est Zpip avec ses thèmes, demain
ça peut être une autre application des plugins différente des autres,
et de fait il y en a déjà plusieurs: méthodes d'authentification par
exemple. Le système de plugins a été justement conçu pour être
générique.

Oui c'est un mécanisme de distribution

À côté de ça, une notion de catégorie a récemment été introduite et
permet de grouper ces plugins par familles, de façon souple et
réactive, sans devoir repenser le code de SPIP à chaque apparition
d'une nouvelle famille.

Du coup, est-ce que ça ne ferait pas sens de continuer à considérer les
thèmes Zpip comme des plugins, car c'est ce qu'ils sont techniquement,
et simplement les grouper dans une catégorie "thèmes du site public" ou
"thèmes Zpip", "thèmes", ou nom équivalent ?

Ben c'est bien le cas, les thèmes ZPIP et Sarka-SPIP possède la catégorie "Thèmes". Je crois qu'il faudrait que tu relises mon mail, il me semble que tout ce que tu dis est déjà dedans...

Ensuite, dans l'interface (et pourquoi pas dans la hiérarchie des
dossiers, si les plugins deviennent nombreux), la séparation peut se
faire suivant ces catégories, en se fendant même d'une petite icône pour
chacune, si on veut. De cette manière les thèmes seront effectivement
séparés du reste, mais par un processus plus générique.

Ca c'est en cours d'une façon plus ou moins équivalente.
Pour avoir une idée de l'interface de recherche et de gestion des plugins du futur, jette un oeil à cette adresse: http://www.circaete.net/spip_doc/step/