[SPIP Zone] ! Plugin Champs Extras (_plugins_/_dev_/champs_extras/)

Archives Zone
1

Hello all !

Voilà, ces derniers jours, en voulant bien faire, je me suis retrouvé à recréer un plugin pour les champs extras de SPIP mais pas des sérialisés comme les anciens de SPIP. Ici, un champ extra = une colonne SQL d'une table.

C'était parti d'un truc tout bête de tutoriel pour ajouter un PS sur les rubriques... Puis ça a fini par devenir quelque chose de générique et généralisable.

Ce plugin dans _dev_/champs_extras/ dispose d'un core et d'une interface. Le core sert simplement à afficher les champs déclarés extras dans les formulaire d'édition (pour l'instant simplement rubriques, articles et auteurs - je n'ai pas testé les autres) et à prendre en compte les saisies des rédacteurs dans ces champs.

Des plugins (comme l'exemple 'extensions/postscriptum') peuvent déclarer des champs à prendre en compte comme ça. Un plugin d'interface graphique a aussi été développé permettant de créer des champs à la volée depuis l'interface privée de SPIP. Il permet aussi d'indiquer que des champs déjà présents dans des tables de SPIP mais non déclarés (merci à Fil qui avait déjà produit le code de recherche de ces champs dans le plugin extra2) puissent aussi être traités comme extras via l'interface.

Tout semble bien fonctionner, avec une limitation de taille pour certains je pense, c'est que ça ne reprends pas les mêmes fonctionnalités que les champs extras originels : pour l'instant, seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas encore question de listes radio, checkbox ou select, mais si ça tente quelqu'un ! Qu'il le fasse !

J'attends donc quelques tests de fonctionnement et quelques retours avant de publier une doc sur SPIP Contrib et de le passer en stable.

Pour info, les tutoriels ayant construit le plugin, dans l'ordre :
- http://marcimat.magraine.net/Ajouter-un-champ-dans-une-table
- http://marcimat.magraine.net/Ajouter-des-champs-dans-une-table
- http://marcimat.magraine.net/Creer-une-interface-d
- http://marcimat.magraine.net/Outils-de-debug
- http://marcimat.magraine.net/Interfaces-extras

A vous les studios !

--
MM.

2

Si je puis me permette, le fonctionnel étant différent des champs Extras historiques, il serait judicieux de nommer le plugin autrement pour éviter toute confusion ("champs supplementaires" ou autre synonyme), car on va se retrouver avec 2 plugins nommés identiquement qui font des choses différentes :
- les utilisateurs ne vont pas savoir quel plugin télécharger
- le support va être source de quiproquos sans fin

Mais sinon ça a l'air cool.
Cédric

Le 28 déc. 08 à 14:09, Matthieu Marcillaud a écrit :

Hello all !

Voilà, ces derniers jours, en voulant bien faire, je me suis retrouvé à recréer un plugin pour les champs extras de SPIP mais pas des sérialisés comme les anciens de SPIP. Ici, un champ extra = une colonne SQL d'une table.

C'était parti d'un truc tout bête de tutoriel pour ajouter un PS sur les rubriques... Puis ça a fini par devenir quelque chose de générique et généralisable.

Ce plugin dans _dev_/champs_extras/ dispose d'un core et d'une interface. Le core sert simplement à afficher les champs déclarés extras dans les formulaire d'édition (pour l'instant simplement rubriques, articles et auteurs - je n'ai pas testé les autres) et à prendre en compte les saisies des rédacteurs dans ces champs.

Des plugins (comme l'exemple 'extensions/postscriptum') peuvent déclarer des champs à prendre en compte comme ça. Un plugin d'interface graphique a aussi été développé permettant de créer des champs à la volée depuis l'interface privée de SPIP. Il permet aussi d'indiquer que des champs déjà présents dans des tables de SPIP mais non déclarés (merci à Fil qui avait déjà produit le code de recherche de ces champs dans le plugin extra2) puissent aussi être traités comme extras via l'interface.

Tout semble bien fonctionner, avec une limitation de taille pour certains je pense, c'est que ça ne reprends pas les mêmes fonctionnalités que les champs extras originels : pour l'instant, seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas encore question de listes radio, checkbox ou select, mais si ça tente quelqu'un ! Qu'il le fasse !

J'attends donc quelques tests de fonctionnement et quelques retours avant de publier une doc sur SPIP Contrib et de le passer en stable.

Pour info, les tutoriels ayant construit le plugin, dans l'ordre :
- http://marcimat.magraine.net/Ajouter-un-champ-dans-une-table
- http://marcimat.magraine.net/Ajouter-des-champs-dans-une-table
- http://marcimat.magraine.net/Creer-une-interface-d
- http://marcimat.magraine.net/Outils-de-debug
- http://marcimat.magraine.net/Interfaces-extras

A vous les studios !

--
MM.

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

3

Super!!
J'étais simplement en train de faire la même chose de mon côté en utilisant cfg afin de créer une colonne sup dans les tables listées.
Pour ce qui est des boutons type radio ou liste déroulante ça fonctionne bien dans la page rédactionnelle, j'avais un souci côté typo dans les champs texte ou textarea.

Mais bon, je vais arrêter , ça ferait doublon :wink:

Bonne fin d'année

Bernard

Matthieu Marcillaud a écrit :

Hello all !

Voilà, ces derniers jours, en voulant bien faire, je me suis retrouvé à recréer un plugin pour les champs extras de SPIP mais pas des sérialisés comme les anciens de SPIP. Ici, un champ extra = une colonne SQL d'une table.

C'était parti d'un truc tout bête de tutoriel pour ajouter un PS sur les rubriques... Puis ça a fini par devenir quelque chose de générique et généralisable.

Ce plugin dans _dev_/champs_extras/ dispose d'un core et d'une interface. Le core sert simplement à afficher les champs déclarés extras dans les formulaire d'édition (pour l'instant simplement rubriques, articles et auteurs - je n'ai pas testé les autres) et à prendre en compte les saisies des rédacteurs dans ces champs.

Des plugins (comme l'exemple 'extensions/postscriptum') peuvent déclarer des champs à prendre en compte comme ça. Un plugin d'interface graphique a aussi été développé permettant de créer des champs à la volée depuis l'interface privée de SPIP. Il permet aussi d'indiquer que des champs déjà présents dans des tables de SPIP mais non déclarés (merci à Fil qui avait déjà produit le code de recherche de ces champs dans le plugin extra2) puissent aussi être traités comme extras via l'interface.

Tout semble bien fonctionner, avec une limitation de taille pour certains je pense, c'est que ça ne reprends pas les mêmes fonctionnalités que les champs extras originels : pour l'instant, seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas encore question de listes radio, checkbox ou select, mais si ça tente quelqu'un ! Qu'il le fasse !

J'attends donc quelques tests de fonctionnement et quelques retours avant de publier une doc sur SPIP Contrib et de le passer en stable.

Pour info, les tutoriels ayant construit le plugin, dans l'ordre :
- http://marcimat.magraine.net/Ajouter-un-champ-dans-une-table
- http://marcimat.magraine.net/Ajouter-des-champs-dans-une-table
- http://marcimat.magraine.net/Creer-une-interface-d
- http://marcimat.magraine.net/Outils-de-debug
- http://marcimat.magraine.net/Interfaces-extras

A vous les studios !

4

Matthieu Marcillaud a écrit :

Voilà, ces derniers jours, en voulant bien faire, je me suis retrouvé à recréer un plugin pour les champs extras de SPIP mais pas des sérialisés comme les anciens de SPIP. Ici, un champ extra = une colonne SQL d'une table.

Chapeau, bravo !
Ce plugin naissant sera surement l'un des piliers de l'extension de spip !
Merci d'avoir innové aussi, avec le "monter" et "descendre"
bien utile en pratique !

Bises de fins d'années,
JLuc

5

(...)

La lecture des pages sur magraine me montre aussi la richesse
... et la complexité ...
de l'API SPIP : un vrai "framework" comme il est coutume de dire,
puissant certes, mais dont l'apprentissage nécessite un temps
désormais non négligeable !

Question 'organisation' la disposition de cette riche doc sur magraine
pose aussi la question de l'éparpillement de la doc.
Ya-t-il une vision globale à ce sujet ?

Ce serait bien de rassembler, ou du moins de relier aussi richement
que possible les éléments pertinents et épars
et autrement qu'avec mercigoogle...

Justement, à propos de liens riches/denses et d'apprentissage;
magraine fait un grand usage de "coloration_code".

Pour des documents pédagogiques comme ceux ci,
ce serait super que "coloration_code" insère des liens automatiques
dans les codes colorés, vers la doc :
- vers doc.spip.org ce serait le plus de valeur ajoutée pour les pages de marcimat
- vers php.net ce serait le plus grand public
  (pour d'autres pages généralistes que celles de marcimat)
- vers spip.net pour les éléments du langage SPIP

Joyeux noël,
JLuc

6

JLuc a écrit :

Ce serait bien de rassembler, ou du moins de relier aussi richement
que possible les éléments pertinents et épars

J'y travaille, azerttuy y travaille, rastapopulos y travaille, paulbe y travaille, les traducteurs y travaillent... Chacun y travaille comme il peut avec ses envies et ses moyens.

Personnellement j'essaie de rassembler des éléments de doc dans mon coin pour l'instant et de les structurer (non, c'est pas visible). Et... c'est loin d'être facile. Il est bien plus facile je crois de réaliser des sortes de "tutoriels" qui parlent de choses au moment où on en a besoin (comme les articles que j'ai pondu récemment) que de doc structurée. Mais j'y crois...

Justement, à propos de liens riches/denses et d'apprentissage;
magraine fait un grand usage de "coloration_code".

Pour des documents pédagogiques comme ceux ci,
ce serait super que "coloration_code" insère des liens automatiques
dans les codes colorés, vers la doc :
- vers doc.spip.org ce serait le plus de valeur ajoutée pour les pages de marcimat
- vers php.net ce serait le plus grand public
    (pour d'autres pages généralistes que celles de marcimat)
- vers spip.net pour les éléments du langage SPIP

Oui, j'ai découvert que c'était possible en reprenant ce plugin coloration code l'autre jour, je connaissais pas du tout geshi, mais on peut effectivement lier un nom de fonction, plus précisément un groupe de fonctions, à des urls.

JLuc, yaka, n'hésite : c'est par ici : Connexion · GitLab

Il suffit de créer un php-spip.php basé sur php.php et ajouter des fonctions de SPIP... mais comme un nombre assez important s'utilisent avec $nom_fonction(), elles ne seont pas prises en compte... Enfin, le second est spip2.php pour les squelettes (spip.php est là pour histoire je dirais).

--
MM.

7

cedric.morin@yterium.com a écrit :

il serait judicieux de nommer le plugin autrement pour
éviter toute confusion ("champs supplementaires" ou autre synonyme),

Fil propose de le nommer "Extras2", ce qui me convient assez bien.
Nous avons aussi l'idée de Realet "ExtraOrdinaires"

Le 28 déc. 08 à 14:09, Matthieu Marcillaud a écrit :

pour l'instant,
seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas encore question de listes radio, checkbox ou select, mais si ça tente quelqu'un ! Qu'il le fasse !

Ouais, alors là, Fil a pensé un truc intéressant. Plutôt que de gérer l'ensemble des trucs possibles et imaginables par ce plugin, proposer de faire comme pour les crayons, des squelettes 'vues' et des squelettes 'contrôleurs' (nommage pas adéquat par ailleurs vis à vis de MVC, puisque ces squelettes ne contrôlent pas des actions utilisateurs, mais affichent des contrôles de formulaires, ceci dit, il suffit juste de le savoir).

Encore faut-il trouver le bon moyen de réaliser ça. Mais ça semble le plus pertinent et le plus évolutif.

--
MM.

8

seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas
encore question de listes radio, checkbox ou select, mais si ça tente

Ca a bien avancé : on sait maintenant ajouter des "blocs"
(post-scriptum sur une rubrique) ou des "lignes" (prénom chez un
auteur), mais aussi par exemple donner un auteur à une brève, en
quelques minutes. Il suffit pour cela de créer le champ
(spip_breves.id_auteur), un masque de saisie pour ce type de champ
(voir le fichier extras-saisies/auteur.html pour un exemple de menu
déroulant), et éventuellement un affichage moins barbant que la donnée
brute (voir le fichier extras-vues/auteur.html pour un exemple).

-- Fil

9

Ce sujet m'intéresse et si je peux me permettre deux ou trois questions:
En ayant lu l'article excellent sur le blog de Matthieu, j'ai cru comprendre que les colonnes de champs dans la base de données sont nouvellement crées et donc à quoi sert de conserver la colonne Extra dans les tables? (Pour les upgrades peut-être?)

Ensuite je ne comprends pas ceci:
<div dir='#LANG_DIR' class='#EDIT{ps} *ps*'>[(#PS|image_reduire{500,0})]</div>
A quoi sert le second ps dans le cas présent après #EDIT{ps}? J'avoue ne pas comprendre mais si je change ça, rien n'est pris en compte dans la BDD
Voilà deux petites questions peut être ridicules mais qui aimeraient trouver une réponse pour mon information...

Merci

BB

Fil a écrit :

seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas
encore question de listes radio, checkbox ou select, mais si ça tente
        
Ca a bien avancé : on sait maintenant ajouter des "blocs"
(post-scriptum sur une rubrique) ou des "lignes" (prénom chez un
auteur), mais aussi par exemple donner un auteur à une brève, en
quelques minutes. Il suffit pour cela de créer le champ
(spip_breves.id_auteur), un masque de saisie pour ce type de champ
(voir le fichier extras-saisies/auteur.html pour un exemple de menu
déroulant), et éventuellement un affichage moins barbant que la donnée
brute (voir le fichier extras-vues/auteur.html pour un exemple).

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

10

Fil a écrit :

seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas
encore question de listes radio, checkbox ou select, mais si ça tente

Ca a bien avancé : on sait maintenant ajouter des "blocs"
(post-scriptum sur une rubrique) ou des "lignes" (prénom chez un
auteur), mais aussi par exemple donner un auteur à une brève, en
quelques minutes. Il suffit pour cela de créer le champ
(spip_breves.id_auteur), un masque de saisie pour ce type de champ
(voir le fichier extras-saisies/auteur.html pour un exemple de menu
déroulant), et éventuellement un affichage moins barbant que la donnée
brute (voir le fichier extras-vues/auteur.html pour un exemple).

Fil a ajouté en plus une sélection "oui/non", et de plus maintenant, les conflits d'éditions sont correctement gérés sur les champs extras ajoutés. Par ailleurs il n'y a plus à l'affichage autant de requête SQL que de champ, mais bien un seul pour tous les champs extras d'une table.

J'ai par contre croisé un autre bug que j'ai pas signalé : on insère des <li> qui sont en dehors du <ul> dans les formulaires... pas glop :slight_smile: (<!--extra--> est en dehors du <ul>, il faudrait encadrer les extras d'un nouvel <ul> ?)

--
MM.

11

Je vous remercie pour votre réponse! Bha c'est pas grave

Bonne année tout de même!

BB

Bernard Blazin a écrit :

Ce sujet m'intéresse et si je peux me permettre deux ou trois questions:
En ayant lu l'article excellent sur le blog de Matthieu, j'ai cru comprendre que les colonnes de champs dans la base de données sont nouvellement crées et donc à quoi sert de conserver la colonne Extra dans les tables? (Pour les upgrades peut-être?)

Ensuite je ne comprends pas ceci:
<div dir='#LANG_DIR' class='#EDIT{ps} *ps*'>[(#PS|image_reduire{500,0})]</div>
A quoi sert le second ps dans le cas présent après #EDIT{ps}? J'avoue ne pas comprendre mais si je change ça, rien n'est pris en compte dans la BDD
Voilà deux petites questions peut être ridicules mais qui aimeraient trouver une réponse pour mon information...

Merci

BB

Fil a écrit :

seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas
encore question de listes radio, checkbox ou select, mais si ça tente
        
Ca a bien avancé : on sait maintenant ajouter des "blocs"
(post-scriptum sur une rubrique) ou des "lignes" (prénom chez un
auteur), mais aussi par exemple donner un auteur à une brève, en
quelques minutes. Il suffit pour cela de créer le champ
(spip_breves.id_auteur), un masque de saisie pour ce type de champ
(voir le fichier extras-saisies/auteur.html pour un exemple de menu
déroulant), et éventuellement un affichage moins barbant que la donnée
brute (voir le fichier extras-vues/auteur.html pour un exemple).

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

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

12

[25628] ajoute un utilitaire de conversion des champs extras ancienne
mode en champs extras2 : ?exec=conversion_extras

-- Fil

13

Le 30 déc. 08 à 10:27, Bernard Blazin a écrit :

Je vous remercie pour votre réponse! Bha c'est pas grave

Bonne année tout de même!

BB

Bernard Blazin a écrit :

Ce sujet m'intéresse et si je peux me permettre deux ou trois questions:
En ayant lu l'article excellent sur le blog de Matthieu, j'ai cru comprendre que les colonnes de champs dans la base de données sont nouvellement crées et donc à quoi sert de conserver la colonne Extra dans les tables? (Pour les upgrades peut-être?)

Ensuite je ne comprends pas ceci:
<div dir='#LANG_DIR' class='#EDIT{ps} *ps*'>[(#PS|image_reduire{500,0})]</div>
A quoi sert le second ps dans le cas présent après #EDIT{ps}? J'avoue ne pas comprendre mais si je change ça, rien n'est pris en compte dans la BDD
Voilà deux petites questions peut être ridicules mais qui aimeraient trouver une réponse pour mon information...

:slight_smile:
pour le "ensuite…"
le second "ps" est la classe css et donc ce pourrait être "chapo" ou "monautreclasse"
par contre le premier, avec #EDIT{} doit toujours être le doublon de la balise suivante. De ce que j'ai compris et utilisé pour le plugin Crayons

Claude

Merci

BB

Fil a écrit :

seuls les champs de type "input text" et "textarea" sont gérés. Donc, pas
encore question de listes radio, checkbox ou select, mais si ça tente

Ca a bien avancé : on sait maintenant ajouter des "blocs"
(post-scriptum sur une rubrique) ou des "lignes" (prénom chez un
auteur), mais aussi par exemple donner un auteur à une brève, en
quelques minutes. Il suffit pour cela de créer le champ
(spip_breves.id_auteur), un masque de saisie pour ce type de champ
(voir le fichier extras-saisies/auteur.html pour un exemple de menu
déroulant), et éventuellement un affichage moins barbant que la donnée
brute (voir le fichier extras-vues/auteur.html pour un exemple).

-- Fil
______

14

dlatr a écrit :

:slight_smile:
pour le "ensuite…"
le second "ps" est la classe css et donc ce pourrait être "chapo" ou "monautreclasse"
par contre le premier, avec #EDIT{} doit toujours être le doublon de la balise suivante. De ce que j'ai compris et utilisé pour le plugin Crayons

Claude

Merci pour les explications, c'est plus clair pour moi ainsi!!

Bonne année :wink:

Bernard