je ne suis pas expert mais je touche pas trop mal ma bille en PHP et suis très à l’aise avec les datas
quiproquo… si il faut coder, je code et avec plaisir (mais l’hiver, là, c’est bientôt le début de ma saison)
et tant qu’à faire, je me renseigne au sujet de l’API objet que je veux bien participer à faire avancer… mais pas si c’est au détriment du reste (là, ça commence à prendre une proportion qui commence à me devenir chronophage, presque toxique dans le sens où j’ai l’impression de devoir me « défendre » et que je vire au troll… ce qui n’est absolument pas mon intention)
Justement, je ne comprends pas encore assez bien l’API objet mais je vois clairement sont potentiel.
A titre d’exemple comparatif, l’équivalent dans Wordpress est juste dégueulasse alors que les fondations dans SPIP sont déjà là et plutôt propre et aussi fonctionnel.
C’est juste que ça ne me paraît pas encore suffisamment aboutit. Alors je fais ce que je peux pour me renseigner, comme je peux… en précisant que je réagis à vos réactions et aussi que pour moi cet « exercice social » n’est pas facile
En vous souhaitant une bonne soirée, je fais une pause de quelques jours peut-être pour laisser décanter (en plus, je sens une migraine qui commence à monter et faut que je dorme cette nuit).
pour la mise à jour semi-auto il serait intéressant de préciser « quoi », "d’où, « vers où » et « quand ». Sur cette base là, il sera peut être possible d’utiliser les plugins SPIP autour de REST. Je ne les ai pas encore utilisé (mais peut être bientôt) :
REST Factory - Plugins SPIP nécessite le 1er (« http ») et apporte une couche en plus mais pour GET seulement en l’état actuel
API Collection+JSON - Plugins SPIP est une autre surcouche de « http » qui semble un peu spécialisée « objets éditoriaux ».
Je ne sais pas bien l’intérêt des 2eme et 3eme par rapport au premier et l’un par rapport à l’autre ; mais si des personnes veulent échanger à ce sujet on peut créer un autre fil de discussion.
Pour l’autre point créer des matrices d'info : les données venant de mysql, tu pourrais commencer en interrogeant ton moteur de recherche ou ton IA favorite avec par exemple « représenter matrice de données en mysql ».
Mon objectif ici n’est pas de me faire « aider » dans ce que je veux faire mais bel et bien de trouver comment participer là où je peux et m’y retrouve
Oui mais je n’ai pas été plus précis volontairement car je ne voulais pas faire du hors sujet
Dans le cas de wikiphyto.org, j’ai déjà codé de quoi digérer les datas, de manière assez simple (je n’ai pas là en tête la fonction PHP mais je peux te retrouver ça à un autre moment).
Et pour anecdote, j’identifie les modifications récentes par flux rss qui me donnent les liens vers les pages récemment modifiées que je fais digérer à mon code (je préfère de loin le mot « algorithme » que « ia »).
Dernière anecdote : un autre site qui peut être intéressant pour ce que je veux faire est tela-botanica.
A part ça, les autres sources sont IRL, sur papier… des bouquins, dont, par exemple, l’encyclopédie des plantes bio-indicatrices (exemple de datas).
Je suis passé jeter un oeil au plugin « grappe » et ai repéré un lien mort sur la page : Grappes 3.0 - SPIP-Contrib
Note : Dans certains cas (notamment pour un nouveau site), il peut être préférable d’utiliser le plugin Sélections Éditoriales. N’hésitez pas à regarder de son côté aussi.
après rafraichissement de mémoire et quelques recherches dans la galaxie SPIP :
en effet, c’est vraiment le bordel entre les différents sites de la galaxie car pour un même sujet (tel que objets éditoriaux, en particulier ?)… je me retrouve à me faire balader un peu partout en passant par un moteur de recherche externe (DuckDuckGo en l’occurence). Pour faire court : c’est juste super chiant !
ensuite, pour illustrer mon propos avec une métaphore : c’est comme si pour accéder à une source (d’eau de montagne) qui devrait se trouver juste au-dessus de moi (ou « au-dessous » si on parlait code « bas niveau », donc issu directement du core), je devais me taper 3km de tuyau de différentes sections/matières avec plein de raccords (à vérifier donc, comme c’est le cas en accumulant les plugins et donc dépendances). Pour faire court : le risque de fuite (comprendre maintenance/bugs, par exemples) est juste énorme !
par ailleurs, l’avantage du PHP étant de permettre un codage bas niveau, l’usage du MVC (Modèle = BdD ; Vue = templating ; Contrôleur = core/plugins) et de la POO (Programmation Orientée Objet) en vue de simplifier/optimiser la conception et l’usage des « objets éditoriaux » me semble être une évidence. Cependant, en examinant le code qui m’est proposé (API objet du core, pas très accessible il faut bien le reconnaître ; plugins divers), la présence conceptuelle ET textuelle de la BdD est un soucis… bien que la partie « Modèle » du MVC soit déjà en place (les objets sont super propres quand on regarde la BdD, et ça c’est très bien car, sans mauvais jeu de mot… c’est la « base » !).
Je ne me souviens pas mot-pour-mot de la citation que j’ai en tête mais en substance : « Pour te dire si c’est bien codé, montre-moi tes données ».
Hé ben chez SPIP, du point de vue MVC+POO (au sujet des « objets éditoriaux » SPIP), on arrive à faire des gribouillis avec le code alors que les données sont super bien rangées !
A titre de comparaison (qui vaut ce qu’elle vaut), le code équivalent aux « objets éditoriaux » chez Wordpress est relativement propre… mais la BdD est juste dégueulasse
Du coup, j’aurais bien des propositions à vous faire… mais ça implique beaucoup alors que, conceptuellement, c’est super simple.
Par exemple, pour commencer, il faudrait que ce soit beaucoup moins le bordel dans la galaxie, au moins au sujet de l’API « objets » pour laquelle on devrait avoir une page de référence qui nous présente le truc simplement (ce qui est déjà un peu le cas) ET contiennent de manière bien lisible (donc après réorga galaxie SPIP) les liens vers code/search, vers plugins, vers discuter, etc.
Ensuite, le code :
une classe avec, par exemples, les méthodes ajouter_objet(), modifier_objet(), supprimer_objet(), lire_objet(), afficher_objet(), trouver_objet(), ajouter_enfant(), … trouver/recuperer_enfants() … etc.
puis, viendrait l’usage de cette API (r)évolutionnée par les plugins : du plugin crayon au plugin fabrique en passant par le plugin coordonnees et toute une ribambelle qui utiliseraient alors les méthodes de cette classe/API « objet.s » (en fait, par exemple, une classe PHP au pluriel pour manipuler plusieurs objets à la fois, donc des listes d’objets éditoriaux, c’est toujours pratique, et une autre classe PHP au singulier pour manipuler les objets de manière unitaire, c’est aussi très pratique).
Ya sûrement des bêtises dans le tas, mais, dans l’ensemble, j’espère que vous captez l’idée… non ?
(plein de trucs sur le feux IRL donc je m’absente quelques jours et reviens voir si je suis compris ou me fais juste traiter de troll… bonne lecture et chaleureux soleil… ou jolis nuages
Je n’arrive toujours pas à comprendre si tu parles de manque dans l’API pour déclarer des nouveaux types d’objets, ou si tu parles de manque dans l’API pour manipuler les contenus de ces objets déclarés.
Et ensuite il y a une page qui regroupe l’API des fonctions centrales pour manipuler les contenus de ces objets, donc pour les ajouter, modifier, etc : API « editer_objet » - SPIP
Et une autre pour manipuler les liens entre objets (quand ils ont des tables de liens) : API editer_liens - SPIP
Là t’as 90% de ce qu’il y a à savoir sur l’ajout de type d’objet, et la manipulation de contenu, et ya rarement besoin de plus.
Donc à partir de ces trois grandes choses, il manque quoi concrètement (en doc, ou en fonctionnalité non fournie qui te manque) ?
L’intégrer dans le core non, comme ça a déjà été dit. C’est un outil pour le développement uniquement.
Par contre, La fabrique génère des fichiers qui ne s’appuient, justement, que sur l’API du core.
Et ces fichiers générés sont de très bons exemples des bonnes pratiques préconisées aujourd’hui pour gérer de nouveaux objets (structure des données, formulaires de création, modification, gestion des liaisons…)
@nicod moi je les verrai surtout sur Programmer, vu que ce sont vraiment uniquement des docs de programmation en PHP pour des devs, et que donc j’ai jamais trop compris pourquoi c’était mélangé dans le site qui a majoritairement la doc d’utilisation (admin) et d’intégration (squelettes, html, etc), alors que la doc majoritairement PHP/dev/APIs est sur Programmer depuis un bail. Donc à déplacer carrément (avec une redirection permanente pour pas perdre).
Alors ça fait longtemps qu’on dit que tout ce qui concerne les API devrait être sur programmer. Yakafokon quelqu’un qui soit admin sur les deux pour migrer ça.
Ensuite si effectivement on pouvait renvoyer les liens via .htaccess (sans article virtuel sur spip.net) ce serait bien.
(mais l’hiver, là, c’est bientôt le début de ma saison)
