Salut,
je me suis fait une note (à partir des infos trouvées sur plusieurs articles contrib) pour créer des champs extras depuis un plugin perso avec Saisies :
https://notes.cousumain.info/Creer-des-champs-extras-depuis-un-plugin-perso-avec-l-aide-de-Saisies
Est-ce que je le mets quelque part sur contrib ? Si oui, dans la rubrique Les champs extra ? Dans Carnet Wiki (pas sûr que ça soit l'endroit idéal pour le retrouver) ?
jeanmarieje me suis fait une note (à partir des infos trouvées sur plusieurs articles contrib) pour créer des champs extras depuis un plugin perso avec Saisies :
Créer des champs extras depuis un plugin perso avec l'aide de Saisies - Carnet de notes
C'est un sujet intéressant et qui mérite des explications.
Est-ce que je le mets quelque part sur contrib ? Si oui, dans la rubrique Les champs extra ? Dans Carnet Wiki (pas sûr que ça soit l'endroit idéal pour le retrouver) ?
Oui, sur contrib dans champs extra.
Peut être pourrais tu introduire l'exemple que tu donnes
en expliquant ce qu'il fait et quels champs extra sont gérés par exemple,
et en donnant une capture d'écran du résultat.
JL
je me suis fait une note (à partir des infos trouvées sur plusieurs articles contrib) pour créer des champs extras depuis un plugin perso avec Saisies :
Créer des champs extras depuis un plugin perso avec l'aide de Saisies - Carnet de notesC'est un sujet intéressant et qui mérite des explications.
Je ne peux qu'abonder dans ce sens ayant misérablement échoué malgré la lecture de tout ce que j'ai trouvé. Faudrait faire une présentation type 'champs extras pour les nuls'
Bé ya déjà tout ici dans ce chapitre non ?
https://contrib.spip.net/Champs-Extras-3-API-et-creations#Creer-un-plugin-en-utilisant-les-API-de-Champs-Extras
S'il manque quelque chose, je dirais plus d'ajouter ce qui manque à cet endroit plutôt que de refaire un autre article complet qui va doublonner 95% de la même chose.
Peut être ça doublonne certaines ou toutes les informations techniques, mais ça a l'air beaucoup plus simple.
Et cette simplicité disparaîtrait si on ajoutait encore à la doc déjà présente.
JLuc
Informations techniques ? Euh le lien avec ancre que j'ai pointé c'est rigoureusement pile la même chose : trois exemples concrets de comment déclarer des champs en PHP et comment lancer la fonction d'upgrade. On peut difficilement faire plus la même chose c'est la fonction XXX_declarer_champs_extras() avec des exemples de champs dedans, puis la fonction XXX_upgrade() avec le lancement des fonctions…
Ya déjà 3 exemples différents dans l'article… je vois mal l'intérêt d'en rajouter un 4ème pour dire encore pareil.
- Soit faut mettre à jour l'article existant pour corriger/améliorer avec tel ou tel mini point qui manquerait.
- Soit faut carrément tout virer de l'article existant, et mettre tous les exemples dans un article dédié (mais 3 max c'est déjà largement suffisant pour tout montrer à priori)
ce que je vois comme intéret de l'article de Jean-Marie est qu'il est hyper condensé. Il s'agit plus d'un memento que d'un tuto en fait.
Mais est-ce la peine de le publier sur contrib, je sais pas. c'est la première fois que le cas du memento sur pose.
C'est une contribution et c'est un élément de documentation, donc elle a sa place sur contrib.
Que les codeurts se prennent a tête avec des critères tellement exigeants qu'ils en deviennent ésotériques
-- au point de se dégoûter eux mêmes l'un l'autre et d'arrêter de contribuer parfois --
je peux le comprendre si c'est pour aboutir à un code irréprochable.
Mais si les critères de contribution devenaient également trop ésotériques pour contrib.spip
ça va restreindre la participation à SPIP aux seuls détenteurs d'une prétendue orthodoxie spipement correcte
et ça va serait assez sinistre.
JL
Mais de quoi tu parles *concrètement* à inventer des trucs là ?
C'est assez simple pourtant :
- ya déjà une doc existante qui contient des *exemples concrets* pas du tout abstraits ou que sais-je que tu t'imagines tout seul
- la doc proposé par Jean-Marie est un simple exemple concret
- donc si on l'intègre c'est en améliorant l'existant, ya pas à lister 40 exemples à la fois pour dire 40 fois la même chose juste avec d'autres noms de champs…
- là ya déjà 3 exemples, perso je trouve ça déjà trop compliqué (des ajouts sur des ajouts), donc on peut même simplifier l'article existant, améliorer c'est pas que rajouter hein, en mettant moins d'exemples (même revenir à un seul mais plus complet ?)
On parle pas de PDF qu'on peut pas modifier là… on parle d'un site en SPIP dans lequel on peut continuer d'éditer et améliorer les articles existants. Le but c'est pas d'accumuler des couches et des couches similaires, on ajoute un article s'il dit vraiment un nouveau truc différent à priori.
Yo !
Vous avez tous les 3 raisons (allez, c'est 1er mai, c'est une fête 
).
J'ai fait cet article parce qu’effectivement, en débarquant sans savoir comment faire, l'article pointé par Rasta (qui est bien sûr une des sources que j'ai utilisées) me paraissait dense et je n'avais pas besoin (ou conscience d'avoir besoin) de toute la partie autorisation. Ma question était "Comment on fait des champs extras depuis un plugin perso" (donc uniquement le 3e point du sommaire) et je cherchais une explication façon fais ça, puis ça, puis ça et ça marche et qu'on me montre des exemples.
Bien sûr, en y retournant par la suite, je vois bien que l'article propose tout ça, mais quand j'ai débarqué, ça me paraissait compliqué et/ou noyé dans autre chose. Donc je me suis fait un mémo. Voilà pour l'historique...
Alors peut être que ça vaudrait le coup de scinder l'article en 2 et faire un nouvel article avec des exemples concrets pour ne pas noyer encore plus l'existant ?
Un truc avec lequel j'ai un peu galéré aussi, c'est la syntaxe des champs. On a bien la référence ici https://contrib.spip.net/Reference-des-saisies mais je n'ai pas tout trouvé. On pourrait imaginer des exemples allant du plus simples (notion ô combien subjective ) au plus complet pour essayer de présenter toutes les syntaxes ?
Voilà voilà, bon 1er mai à tou.tes
jeanmarie+1 c'est ce que je disais avec :> - Soit faut carrément tout virer de l'article existant, et mettre tous les exemples dans un article dédié (mais 3 max c'est déjà largement suffisant pour tout montrer à priori)
Dans l'article de doc de l'API, il faudrait remplacer cette partie par juste présenter les 2 ou 3 fonctions à utiliser, et ce qu'elles attendent comme params, avec ensuite un lien "Voir des exemples" amenant à l'autre article.
Dans l'article d'exemple, là actuellement on a trois exemples issus de l'article actuel + le tien. Je pense que c'est beaucoup trop. Il faudrait donc simplifier, remettre au propre, en ne faisant par exemple que deux exemples, un très simple avec les choses de base, et un compliqué avec les choses avancées. Ça devrait suffire il me semble.
Ok, si ça va à tout le monde, je prépare l'article d'exemples et on avise...
jeanmarieOk, si ça va à tout le monde, je prépare l'article d'exemples et on avise...
jeanmarie
oui moi ca me va 
J'ai développé un plugin et j'ai bien galéré à intégrer les champs extras via le plugin, surtout pour mes mises à jour.
L'exemple de Jean-Marie est clair
C'est assez simple pourtant :
- ya déjà une doc existante qui contient des *exemples concrets* pas du tout abstraits ou que sais-je que tu t'imagines tout seul
Ce que j'écris je l'écris tout seul avec mon clavier, et je l'imagine tout seul, comme toi quand tu te sers d'un.
- la doc proposé par Jean-Marie est un simple exemple concret
Je dirai même mieux : c'est un exemple concret et simple.
- donc si on l'intègre c'est en améliorant l'existant, ya pas à lister 40 exemples à la fois pour dire 40 fois la même chose juste avec d'autres noms de champs…
- là ya déjà 3 exemples, perso je trouve ça déjà trop compliqué (des ajouts sur des ajouts), donc on peut même simplifier l'article existant, améliorer c'est pas que rajouter hein, en mettant moins d'exemples (même revenir à un seul mais plus complet ?)
Cette manière très structurée de présenter les choses donne l'impression d'une grande clarté et l'exposé est de ce fait assez convaincant.
Mais plus complet ne veut pas dire mieux si ça devient moins accessible.
Il y a plein de manière d'accéder à l'information.
Des articles que tu as rédigé me sont totalement hérmétiques alors qu'ils ont l'air très clairs et bien structurés.
Par exemple :
Je n'avais pas fini mon mail. Voici :
C'est assez simple pourtant :
- ya déjà une doc existante qui contient des *exemples concrets* pas du tout abstraits ou que sais-je que tu t'imagines tout seul
Ce que j'écris je l'écris tout seul avec mon clavier, et je l'imagine tout seul, comme toi quand tu te sers d'un clavier aussi.
- la doc proposé par Jean-Marie est un simple exemple concret
Je dirai mieux : c'est un exemple concret et simple.
- donc si on l'intègre c'est en améliorant l'existant, ya pas à lister 40 exemples à la fois pour dire 40 fois la même chose juste avec d'autres noms de champs…
- là ya déjà 3 exemples, perso je trouve ça déjà trop compliqué (des ajouts sur des ajouts), donc on peut même simplifier l'article existant, améliorer c'est pas que rajouter hein, en mettant moins d'exemples (même revenir à un seul mais plus complet ?)
Cette manière très structurée de présenter les choses donne l'impression d'une grande clarté et l'exposé est de ce fait assez convaincant.
Mais plus complet ne veut pas dire mieux si ça devient moins accessible.
Il y a plein de manière d'accéder à l'information et de se l'approprier.
Des articles que tu as rédigé me sont totalement hérmétiques alors qu'ils ont l'air très clairs et bien structurés.
Je pense par exemple à la doc du plugin "http" sur l'API REST : alors que j'ai déjà codé et utilisé nombre d'APIs, je n'arrive pas du tout à rentrer dans ton article Serveur HTTP abstrait - SPIP-Contrib
Un référentiel complet ne remplace pas un tutoriel simple dans lequel on rentre sans effort et dont on fait rapidement le tour.
On parle pas de PDF qu'on peut pas modifier là… on parle d'un site en SPIP dans lequel on peut continuer d'éditer et améliorer les articles existants. Le but c'est pas d'accumuler des couches et des couches similaires, on ajoute un article s'il dit vraiment un nouveau truc différent à priori.
On parle pas non plus du mode d'emploi technique d'un moteur de machine à laver construit par une multinationale,
ou une super application genre stopcovid codée par la crème des startup (lol) et pour laquelle les critères de qualités AFNOR xxx s'appliquent.
Les couches ici ne sont pas similaires,
les articles sont très différents,
de même que les spipeurs ne sont pas similaires.
SPIP c'est aussi une communauté d'utilisateur, et contrib.spip.net, comme son nom l'y invite, est un lieu privilégié pour l'expression des talents multiples et variés des spipeurs. Pouvoir intégrer ces divers talents au mieux est une grande force pour un logiciel libre, et il faut aussi prendre en compte dans l'évaluation de ce qui est le mieux.
JLuc
Tu persistes à parler de choses dont personne ne parle. Depuis le début : le morceau pointé CE SONT des tutoriels ! Tu n'arrêtes pas d'argumenter comme s'il s'agissait de refuser un tutoriel parce qu'il y aurait un référentiel, alors que personne n'a parlé de ça et qu'il n'y a aucun rapport avec ça. On parle de tutoriels déjà en place, et d'un ajout de tutoriel supplémentaire, ce qui ferait QUATRE tutos pour dire la même chose. Et donc depuis le début je dis que si les tutos déjà en place ne sont pas corrects, il faut les corriger, améliorer, compléter, ou à l'inverse : simplifier. Ce que jeanmarie a bien compris et donc il est parti pour combiner et avoir tout ce qui est nécessaire en une fois (du genre un exemple simple + un exemple complexe = 2 et ça suffit). Bref depuis le début tu parles de chose qui ne correspondent pas à ce dont on parle en face…
La documentation, contrairement à ce que tu disais plutôt, demande encore plus de relecture que le code. Le code chez nous ya max 3-4 personnes qui vont le voir alors si parfois il est un peu bordélique, c'est un peu embêtant oui mais on s'en sort. Mais si la documentation a 15 articles pour dire la même chose, là ça touche beaucoup plus de monde. Tout comme le code, il ne s'agit pas du tout d'un truc publié qui ne bouge plus ensuite, on peut l'améliorer en permanence. Ce qui est le cas ici. Il est bien plus utile d'avoir 2 tutos bien faits (un simple, un complexe) en un endroit précis, que d'avoir 15 tutos qui disent "un peu pareil mais pas tout à fait", et du coup de pas savoir quoi suivre (ce qui était justement un des problèmes de la doc actuelle).
+10.000
Un référentiel complet ne remplace pas un tutoriel simple dans lequel on rentre sans effort et dont on fait rapidement le tour.
*Tout est dit !*
Effectivement les référentiels complets sont bien utiles, voir indispensables, pour éviter de devoir "plonger" dans le code (je l'ai fait sur Saisies a un moment, car la compréhension initiale du référentiel etait... difficile !).
Mais rien ne remplace *aussi *un exemple pas-à-pas (voire plusieurs) qui apportent une démarche plus progressive, avec des termes parfois moins précis, mais bien suffisants pour une première decouverte.
Imaginez-vous de n'apprendre SPIP qu'avec Programmez ?
Pourtant il y a tout dedans.....
Manifestement, il a été nécessaire a divers nombreux spipeurs de commencer par autre chose, avant de se concentrer sur la lecture des seuls référentiels (et du code source).
Donc, avoir dans les rubriques de Contrib (ou d'ailleurs)
- et les référentiels
- et des tutoriels imparfaits (ou moins précis)
me parait tout\-à\-fait pertinent\.
Salut,
Je pense qu'il faut deux exemples, et que ça suffit. Un "simple", là le premier à juste deux champs ça va. Et un deuxième plus complexe avec plus de choses utilisées (suffit de copier un de l'ancien article). Ça reste des exemples, le but c'est pas forcément d'utiliser 100% de ce qui existe non plus hein… Ya la doc pour liste exhaustivement les fonctionnalités pour ça.
Pour l'ancien article, je pense qu'il faut alors supprimer totalement les exemples, ne laisser que la documentation donc (la liste des fonctions fournies, etc), et faire un lien vers l'article d'exemples.