Objets éditoriaux ?

Dev
#1

Je suis très intéressé par les « objets éditoriaux » et souhaite savoir où ça se passe, où s’en est rendu et bien sur l’avenir de ce concept dans SPIP.

Me concernant, je peux en avoir un usage assez poussé pour différents projets (à vocation encyclopédique, par exemple, mais aussi pour quelque chose de plus « mercantile » comme la gestion d’un groupement d’achat à l’échelle locale et qui pourrait se transposer ailleurs).

Après (rapide) recherche et feuilletage, y compris dans les étiquettes dispos, je n’ai pas trouvé grand chose. C’est pourquoi je créé ce sujet. Si cela n’est pas utile car existant ailleurs mais que je n’ai pas trouvé, n’hésitez pas à me rediriger au bon endroit :slight_smile:

#2

Heu… je ne suis pas sur à quoi tu fais référence.

Dans SPIP « objet editorial » désigne un type de contenu. Un article est un objet éditorial. Un site référencé est objet éditorial. Un mot clé est un objet édiorial.

Après, il est possible de créer un plugin qui te propose de nouveaux objets. Le plugin « fabrique » permet de faire cela relativement facilement.

Enfin, concernant tes beoins, je pense que

  1. Pour la vocation encyclopédique, le plugin « dictionnaire » peut répodnre en partie
  2. Pour les groupements d’achat: il y tout une série de plugin de gestion de commerce en ligne, mais il faudrait en savoir plus (et ce n’est pas mon domaine de spécialité, loins de la)
#3

Ya quand même un article de doc dont le titre est explicitement ce terme là :slight_smile:

#4

Oui, je connais bien le plugin « fabrique » ! :slight_smile:

J’ai même trouvé ses limites avec un projet encyclopédique retourné au placard faute d’un outil suffisamment souple.

Je reste convaincu que SPIP est ma solution. Seulement, il y a énormément de connexion entre les objets éditoriaux que je créé pour ce projet qui est transversal à la botanique et la phytothérapie (entre autres)… et pour lequel le plugin « dictionnaire » n’est absolument pas suffisant (sans remettre aucunement en question ce plugin).

Pour aller plus loin, je pense que le plugin fabrique devrait être intégré au core ou, plus exactement, que c’est le core qui devrait traiter ça.

Pour le.s groupement.s d’achat (Nature&Progrès Lozère et qui pourrait se décliner à d’autres groupes locaux dans les prochains temps car faisant partie de notre stratégie politique sur années à venir), les plugins existants seraient bien évidemment étudié en premier lieu (et par mes soins) avant se lancer tête baissée :slight_smile:

Le commerce en ligne n’étant pas non plus ma spécialité (très loin de là !), je ne connais quasiment pas ces plugins malgré que j’ai déjà un peu farfouillé à ce sujet sur Pluings-SPIP et SPIP-contrib.

#5

Oui, en effet, je le connais bien :slight_smile:

Mais « ici » (discuter.spip.net), je n’ai pas trouvé grand chose… pour l’instant !

#6

pour ton problème encyclopedique, peut être que le travail de @eric_tonton sur la taxonimie peut aider?

#7

Pour les architectures non pyramidales

voir aussi Polyhiérarchie - SPIP-Contrib

1 « J'aime »
#8

Important pour me comprendre à ce sujet : derrière les « objets éditoriaux », je vois « Programmation Orientée Objet » (POO).

Les deux exemples cités, le projet « encyclopédique » et le projet « groupement.s d’achat », bien que m’intéressant grandement et y ayant déjà consacré beaucoup de temps dans la pratique et la réflexion, ne sont ici que des exemples du potentiel que je vois dans les « objets éditoriaux » SPIP (au sens large).

On m’a souvent conseillé Symphony mais ça m’est tout simplement hermétique.

A cela j’ajoute que SPIP me paraît beaucoup mieux correspondre au contexte IRL que tout autre outil croisé sur mon chemin (recherches et conseils compris).

#9

Je ne pense pas, ça fait des années qu’on sort des fonctionnalités du core pour qu’elles soient autonomes dans des plugins, cela irait à l’inverse de ce mouvement. Et puis, le besoin de créer des objets persos me semble tout de même réservé à un usage avancé qui amha peut très bien rester dans un plugin et non dans le core.

1 « J'aime »
#10

Oui, c’est ce qu’il me semblait avoir compris :slight_smile:

Pourtant, si j’ai bien compris (?), il s’agit bien de la même mécanique algorithmique que pour les articles, les rubriques, les mots-clefs, etc.

Alors pourquoi ne pas étendre (pas forcément beaucoup) cette fonctionnalité dans le core ?

L’introduction d’objets éditoriaux (si pertinents bien sur sinon je plains la pauvre BDD) serait alors plus aisée à travers des plugins, par exemple, et ce sans nécessité le plugin « fabrique »… non ?

Exemples d’objets éditoriaux transversaux et utilisables par d’autres plugins (ya sûrement des bêtises mais ce ne sont que des exemples) : contact, adresse, lieu, etc.

Par contre, ça nécessiterait de bien faire attention quand on veut introduire un nouvel objet pour raison de compatibilité générale avec les autres plugins. Si chacun.e se met à créer un objet « contact », ça va vite être le bordel, je reconnais.

NB : tout ça me permet de mieux comprendre SPIP à travers nos échanges. Même si ça ne débouche pas sur ce qui m’intéresse perso, ça me forme un peu au passage :slight_smile:

#11

Alors pourquoi ne pas étendre (pas forcément beaucoup) cette fonctionnalité dans le core ?

par cohérence, parce que une fois l’objet créé, il n’y a rien pour l’afficher : dans tous les cas reste un travail technique à faire

L’introduction d’objets éditoriaux (si pertinents bien sur sinon je plains la pauvre BDD) serait alors plus aisée à travers des plugins, par exemple, et ce sans nécessité le plugin « fabrique »… non ?

ta phrase me parait contradictoire : tu parle de créer des objets à travers des plugins, mais sans fabrique. Mais c’est justement à cela que sert fabrique : à créer des plugins qui créent des objets. Une fois le plugin créé, on n’a plus besoin de fabrique. Fabrique c’est vraiment un outil pour les gens qui font du dev.

Exemples d’objets éditoriaux transversaux et utilisables par d’autres plugins (ya sûrement des bêtises mais ce ne sont que des exemples) : contact, adresse, lieu, etc.

bah pour ca on a deja des plugins qui font l’affaire : contact et organisation, gis. Précisement le fait d’avoir mis cela dans des plugins dédiés et ne pas permettre « nativement » à tout un chacun de créer cela permet d’éviter d’avoir 36 implémentations différentes pour le meme besoin.

1 « J'aime »
#12

ps : quand à ta remarque sur les objets editoriaux accessibles en tant qu’objet PHP, c’est tout un travail d’arriver à faire cela, car il faut demeler dans le code de SPIP ce qui releve de l’editorial et ce qui releve de la BDD. Mais il y a un certains @JamesRezo qui se penche en ce moment sur cela. Mais pour l’heure… ca n’existe pas encore totalement (même si l’API de SPIP fournit une base de départ)

1 « J'aime »
#13

Je ne comprends pas trop tes remarques, il me semble que tu as mal compris quelque chose dans le flux de travail : l’API objet fait totalement partie du core et est documentée. La Fabrique est juste un plugin-outil qui AIDE à générer ton propre plugin avec tes propres PHP pour déclarer un ou plusieurs nouveaux objets. C’est juste une interface de travail quoi, et donc elle n’a absolument pas à être ajoutée au core : c’est uniquement pour les quelques devs qui en ont besoin par ci par là, les rares fois où on crée un nouveau plugin.

#14

Si j’avais compris. Je ne parle pas de faire un copier-coller du plugin « fabrique » dans le core de SPIP.

Pour info, ça remonte un peu mais à l’époque (2 ans ?) j’avais épluché le code du plugin « fabrique ». J’avais aussi (tenté) d’éplucher le code de l’API objet dans le core mais je tournais un peu en rond.

Ce que je trouverai pertinent, ce serais d’adapter/remanier/faire évoluer l’API objet pour simplifier/normaliser/étendre l’usage de ces objets sans le plugin « fabrique ».

Ce qui pourrait avoir pour conséquence d’alléger grandement le dit plugin qui, en l’état, me montre assez rapidement ses limites.

Je pourrais me contenter de l’API objet mais, en l’état, ça me ferait développer un énorme plugin alors que les fonctions/méthodes nécessaires ne le seraient pas que pour moi, loin de là.

D’où cette idée de faire évoluer l’API objet depuis le core, collectivement, sur le long terme.

C’est tout.

NB : que l’API objet existe est déjà en soi est une très bonne chose :slight_smile:

#15

Je pense à des objets utilisable pas potentiellement tout plugins.

C’est bien pour ça que je cite « contact », « adresse » et « lieu » qui me paraissent être de très bon exemple.

Et non ma phrase n’est pas contradictoire car la création d’objet passerait directement par l’API objet (dsl, j’avais perdu cette appellation dans les limbes de ma mémoire) et donc sans le plugin « fabrique ».

Vu que je sens qu’on va me rétorquer que je n’ai alors qu’à utiliser l’API objet… j’ajoute que cette API ne me paraît pas assez poussée, qu’on pourrait aller plus loin.

Je pourrais remplacer « on » par « je » ou « nous » mais, en l’état, « je » n’en suis pas capable et concernant le « nous »… je tente dans un premier temps d’aborder le sujet.

Mais bon, vu que tout ça ne me paraît pas très constructif et que j’ai plutôt l’impression de devoir me retrancher dans une position défensive… ça donne pas envie. Pour bémol, ce n’est que mon point de vue individuel avec toute la subjectivité que ça implique.

Là, j’ai juste la tentation de clore le sujet et de voir le résultat du taf de @JamesRezo … si ça aboutit.

#16

Oui, en effet, j’avais bien repéré ce plugin.
Mais, dans ce contexte, ça n’est qu’un accessoire anecdotique.
Le besoin est bien plus large.

#17

Le problème c’est que je (et peut-être on) n’arrive pas du tout à comprendre ton « point de vue ». Je ne comprends pas ce que tu aimerais avoir comme résultat. Les nouveaux objets éditoriaux, c’est purement un truc de dev qui crée un plugin, chaque plugin doit donc déclarer un ou plusieurs objets nouveaux. C’est sans rapport aucun avec une interface où on clique pour créer ces objets, c’est obligatoirement une API qui permet de déclarer ça.

Il faudrait plutôt que tu listes clairement et explicitement ce qui te manque, et notamment ce que tu penses qu’il manque à l’API de déclaration des objets, pour que ça fasse soit « ci ou ça » en plus, soit « ci ou ça » plus facilement qu’actuellement.

1 « J'aime »
#18

(je préfère voir ça comme un projet plutôt que comme un problème :slight_smile: )

Oui, cela passe forcément par la taxonimie, horizontale avec mot-clefs, verticale avec rubriques.

Pour le projet encyclopédique que j’évoque (seulement à titre d’exemple ici pour illustrer mon propos), il serait question de créer un objet parent « plante » qui serait composé de différents objets enfants : « fleur », « fruit », « semence », « tige », « feuille », « racine », etc.

Chacun de ces types d’objets spécifiques disposerait alors donc chacun de sa table en BDD et que l’on pourrait alors « décrire » (cf. champs sql) que ce soit sur le plan botanique (période de floraison, couleur.s, … pour les fleurs, par exemple), sur le plan médicinal (vertu.s, contre-indication.s, etc) ainsi que pour les abeilles (mellifère ? nectar, pollen).

Un autre type d’objet serait alors utile comme « recette » où on pourrait alors utiliser une ou plusieurs partie.s d’une ou plusieurs plantes à vocation médicinale, culinaire… ou même pour la préparation de tisanes pour les abeilles (mieux une infusion de thym pour obtenir du thymol pour que de l’acheter en poudre à l’industrie, par exemple).

Autre exemple de type d’objet dont j’aurais l’utilité : « observation ». Notamment pour faire bouffer à mon « encyclopédie » une étude manuscrite des années 80 contenant de très précieuse informations concernant le comportement (et donc la population) d’abeilles dans les Cévennes comprenant point GPS (cf. champ d’un objet de type « lieu »), date/heure précise, conditions météo, etc.

… à savoir que professionnellement, je suis paysan-phytothérapeute (récolte, culture, transfo et soins) et que je porte un très grand intérêt aux insectes pollinisateurs qui, en plus de piquer très fortement ma curiosité, m’indique aussi quand récolter (la période de l’année, c’est facile, mais pour la période de la journée, ce sont les abeilles les plus précises jusqu’à parfois contredire les humain.e.s même chevronné.e.s).

Bien évidemment, vous vous doutez bien que ça ne s’arrête pas là mais je vous épargne la suite car je souhaite que ce projet ne reste qu’un exemple pour illustrer le potentiel que je vois dans l’API objet de SPIP.

(dsl pour la longueur de l’exemple qui n’en est pas un pour moi)

#19

En effet, d’un côté tu dis que ça ne convient pas, mais tu ne dis pas pour quoi précisément ça ne convient pas à part que ça devrait être « plus poussé » car ton projet est « bien plus large »… et d’un autre côté tu expliques que tu te t’y connais pas beaucoup en code.

Ça me donne l’impression que tu voudrais un truc qui fait directement et clé en main ce dont tu as besoin… alors que SPIP ne fournit « que » des outils pour le faire.

#20

(pour résumer, je voudrais pouvoir créer des matrices d’infos qui pourrait par exemple permettre de créer des synergies inédites sur le plan médicinales en intégrant, par exemple, les datas de wikiphyto.org avec mise à jour semi-auto… mais pour ça il faut que tout soit bien rangé dans la BDD en passant par la POO pour décrire précisément la « réalité »)