Objets éditoriaux ?

Dev
#21

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 :slight_smile: (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)

#22

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 :sweat_smile:

#23

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).

#24

Je suis sincèrement désolé si la conversation est éprouvante…

Selon moi, c’est ce que tu as dit de plus précis sur ton besoin, mais c’est très court et encore insuffisant pour une réponse circonstanciée.

1 « J'aime »
#25

Sur la base de ces indications tout de même,

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) :

  • Serveur HTTP abstrait - Plugins SPIP semble la brique de base
  • 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 ».

#26

Il me semble qu’on commence (?) à confondre dans ce même sujet, deux choses qui n’ont rien à voir :

  • comment résoudre/aider à résoudre, les développements précis que cherchent à faire @Osmy
  • discuter des éventuels manques génériques au noyau, à l’API des objets de SPIP et à l’API des liens
1 « J'aime »
#27

En effet.

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 :slight_smile:

#28

Oui mais je n’ai pas été plus précis volontairement car je ne voulais pas faire du hors sujet :slight_smile:

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).

D’où l’expression « matrice d’info ».

#30

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.

Ce lien menant à une erreur 404, j’ai effectué une recherche. Il semble que la bonne URL soit : Sélections éditoriales - SPIP-Contrib

#31

(même si je me doutais un peu du résultat, j’ai créé un compte pour tenté de rectifié le lien mais je n’ai pas les droits)

#32

file_get_contents() ou stream_get_contents() me suffise largement

#33

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 ! :crazy_face:

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 :face_vomiting:

#34

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 ?

#35

(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 :face_in_clouds:

#36

( @eric_tonton ? @JamesRezo ? d’autres ? )

#37

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. :crazy_face:

En l’occurrence, l’API pour déclarer des nouveaux types, ya bien une unique page qui indique comment faire : API de déclaration d'objets éditoriaux - SPIP

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) ?

1 « J'aime »
#38

Tiens, c’est dommage que ces trois articles ne soient pas classés les uns à la suite des autres.

Je verrais bien, en les renommant :

@documentation ?

Et sinon, @Osmy :

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…)

1 « J'aime »
#39

@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).

2 « J'aime »
#40

@rastapopoulos sans doute pour des raisons historique. Mais la limite entre programmer et spip.net n’est pas forcément claire.

Mais oui je suis d’accord qu’on pourrais modifier.

#41

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.

1 « J'aime »