Si on parle de ce point précis, mieux ouvrir un autre fil parce que là on est en train de pourrir celui de RealET.
Je rebondis sur la proposition que davux car j'ai une petite expérience là-dessus.
Sur un plan pratique, est-ce qu'ajouter un champ id_parent aux articles
ne serait pas suffisant ? En généralisant, est-ce qu'on pourrait se
dire que tout objet doté d'un champ id_parent est hiérarchisable ?
J'ai récemment dû créer à peu près ce que tu proposes.
J'ai un objet "fiche" qui *est* un contenu éditorial, mais qui est *aussi* hiérarchisable grâce à un champ "id_parent".
C'est donc exactement ce que vous proposez depuis le début.
Ensuite, cet objet est "classable" avec l'objet "rubrique" de SPIP : mais je n'utilise que des liens, comme des tags, grâce au plugin Polyhiérarchie.
Techniquement, il m'a fallu reproduire le comportement des rubriques sur les Fiches pour pouvoir boucler par branche notamment. Il a donc fallu que je fasse un critère {branche} pour les fiches car ce critère n'est pour l'instant pas générique et ne marche que pour les rubriques.
Pareil pour la boucle HIERARCHIE que j'ai dû dupliquer en HIERARCHIE_FICHES.
Je ne comprend pas la différence que tu fais entre hierarchisation et classement.
N'aurais-tu pas pu faire tout cela avec la poly-hiérarchie ?
J'ai l'impression que c'est pour avoir une interface différente selon la sorte de contenant,
mais je ne vois pas ce qui justifie une structure de donnée différente.
Peu importe le ou les objets qu'on utilise, le problème est le même :
Si mon *contenu* (titre, texte, plein d'autres champs, des auteurs, etc) est stocké dans un objet AAA qui est hiérarchisé (cf la hiérarchie de mes fiches).
Avec quoi veux-tu que je *classe* ce contenu ? Classer càd donner des étiquettes, des catégories ou tout autre mot que tu préfères. Ça sera forcément avec un *autre* objet que AAA ! Puisque AAA est un objet de contenu avec plein de champs, et qui ne sert absolument pas à classer.
Par exemple "Datation" ou "XIXème siècle" ou "Église" ou "Religieux" n'ont absolument pas à être stocké dans un objet AAA, ya aucun des champs de cet objet de contenu qui correspond. Ces termes sont juste des mots servant à classer les objets AAA.
Donc forcément ça va dans un objet BBB qui a beaucoup moins de champ (essentiellement "titre" et éventuellement un descriptif).
Ça serait complètement fouilli d'utiliser le même objet pour deux besoins totalement différents.
Il y a donc bien plusieurs hiérarchies différentes puisque chaque *contenu* peut avoir des enfants, mais chaque *étiquette/rubrique/catégorie/terme* peut également avoir des enfants (des enfants étiquettes aussi, des enfants du même objet je parle).
Ma question "N'aurais-tu pas pu faire tout cela avec la poly-hiérarchie ?"
questionnait *également* le choix de partir d'objets (fiches) déjà hiérarchisées.
Avec un SPIP de base, on gèrerait tout ce que tu décris avec des rubriques et des motclés,
qui toutes 2 bénéficient d'un titre et d'un descriptif comme ton BBB.
IL y a quelques différences :
- les rubriques sont structurées en hiérarchie (et structurent une hiérarchie)
pas les motclés (mais cette particularité saute avec le plugin momot)
- il peut y avoir plusieurs motclés par article
mais qu'une seule rubrique (mais cette particularité saute avec le plugin multihiérarchie).
Classiquement "donner une étiquette" c'est ajouter un motclé,
mais ça peut aussi être "attribuer une hiérarchie" en multihiérarchie.
Il n'y a pas tant de différences entre tous ces objets comme éléments structurants,
et ce sont en fait leurs limites et leurs interfaces qui définissent les particularités
de leur effet structurant.
L'ajout d'un lien id_parent aux articles se situe au même niveau de questionnement
que ces considérations pour homogénéïser les objets.
J'avoue que cela fait déjà pas mal de temps que j'aimerais me débarrasser des rubriques et n'avoir plus que des articles hiérarchisés, les rubriques étant trop pauvres en termes de structure de contenus, alors qu'elles sont censées représenter des pages à part entière sur les sites.
Cela conduit certains à utiliser des artifices qui font que la page de rubrique affiche en fait un de ses articles, cela étant facilité par le plugin "court-circuit".
Personnellement, j'ai plutôt tendance à utiliser "champs extras" pour rajouter aux rubriques les champs qui leurs manquent.
Se passer des rubriques et n'utiliser plus que des articles hiérarchisés permettrait de plus de faciliter la mise en place de moteurs de recherches dignes de ce nom. Actuellement, soit on présente séparément les articles et rubriques, soit on fait des squelettes super compliqués et pas performants pour mixer différents types de contenus.
Ce serait de plus l'occasion d'adopter un mode de stockage/requêtage des arbres de données bien plus performant (en lecture, y compris pour le critère {branche}) que le modèle actuel, le mode intervallaire : http://sqlpro.developpez.com/cours/arborescence/#L2
l'idée est sympathique, mais je ne suis pas sûr que l'imposer soit la bonne solution. AMHA il faudrait proposer un SPIP brut sans structure, avec deux types d'extensions possibles :
- classement par rubrique
- article arborescents.
Si le modèle intervallaire est puissant, je ne sais pas en revanche s'il est très intuitif pour un débutant en bouclage etc. Perso, la seule fois où j'ai du m'en servir (pour DC 2 SPIP), j'ai mis 3 plombs à comprendre, et seul l'article que tu ref m'a permis d'accéder.
J'ai peur qu'en utilisant un tel modèle on perde encore plus les gens.
J'avoue que cela fait déjà pas mal de temps que j'aimerais me débarrasser des rubriques et n'avoir plus que des articles hiérarchisés, les rubriques étant trop pauvres en termes de structure de contenus, alors qu'elles sont censées représenter des pages à part entière sur les sites.
Cela conduit certains à utiliser des artifices qui font que la page de rubrique affiche en fait un de ses articles, cela étant facilité par le plugin "court-circuit".
Personnellement, j'ai plutôt tendance à utiliser "champs extras" pour rajouter aux rubriques les champs qui leurs manquent.
Se passer des rubriques et n'utiliser plus que des articles hiérarchisés permettrait de plus de faciliter la mise en place de moteurs de recherches dignes de ce nom. Actuellement, soit on présente séparément les articles et rubriques, soit on fait des squelettes super compliqués et pas performants pour mixer différents types de contenus.
Ce serait de plus l'occasion d'adopter un mode de stockage/requêtage des arbres de données bien plus performant (en lecture, y compris pour le critère {branche}) que le modèle actuel, le mode intervallaire : SQLPro - Représentation intervallaire des arborescences
ah, le retour !
il y a eu un premier travail, il y a longtemps, en spip 1 et des poussières, bien avant les plugins. C'était pas un de tes collègues ? C'était prometteur.
"fiche" de RastaPopoulos me fait penser aux mots-clés hiérarchiques de certains Thésaurus. Rapidement : Thésaurus — Wikipédia article que je trouve assez moyen mais bon.
Ce serait de plus l'occasion d'adopter un mode de stockage/requêtage des arbres de données bien plus performant (en lecture, y compris pour le critère {branche}) que le modèle actuel, le mode intervallaire : SQLPro - Représentation intervallaire des arborescences
l'idée est sympathique, mais je ne suis pas sûr que l'imposer soit la bonne solution. AMHA il faudrait proposer un SPIP brut sans structure, avec deux types d'extensions possibles :
- classement par rubrique
- article arborescents.
Le fait de rendre les articles arborescents pourrait être une option décochée par défaut.
Et l'activer ne supprimerait pas forcément les rubriques, utiles à une classification transverse.
Si le modèle intervallaire est puissant, je ne sais pas en revanche s'il est très intuitif pour un débutant en bouclage etc.
Perso, la seule fois où j'ai du m'en servir (pour DC 2 SPIP), j'ai mis 3 plombs à comprendre, et seul l'article que tu ref m'a permis d'accéder.
J'ai peur qu'en utilisant un tel modèle on perde encore plus les gens.
Il doit être possible de conserver les mêmes notations de boucles, ce ne sont «que» les requêtes SQL générées qu'il faut modifier.
Ce serait de plus l'occasion d'adopter un mode de stockage/requêtage des arbres de données bien plus performant (en lecture, y compris pour le critère {branche}) que le modèle actuel, le mode intervallaire : SQLPro - Représentation intervallaire des arborescences
ah, le retour !
il y a eu un premier travail, il y a longtemps, en spip 1 et des poussières, bien avant les plugins. C'était pas un de tes collègues ? C'était prometteur.
Peut-être, oui, je crois me souvenir que nous avions regardé, effectivement.
"fiche" de RastaPopoulos me fait penser aux mots-clés hiérarchiques de certains Thésaurus. Rapidement : Thésaurus — Wikipédia article que je trouve assez moyen mais bon.
Oui, tout ça fait, mais moi ça me fait aussi tout simplement penser à des pages web d'un site, où une page devrait avoir la même richesse qu'elle soit une branche ou une feuille de l'arbre des contenus.
oui et non. Il s'agit de la masquer tout en permettant de découvrir facilement (mais non sans fierté) qu'en réalité on fait la même chose qu'une requte SQL, mais en plus simple. Autrement dit masquer la dimension technique tout en la laissant sous entendue pour ceux qui veulent / souhaite progresser. Cela fait parti de la pédagogie de SPIP : j'ai appris les boucles, et finalement je me rend compte que j'ai appris une base du mysql.
ah, je ne retrouve pas le premier travail (dans spip-lab ?, un nommé guillaume ? de mémoire fléchissante) mais je vois que d'autres travaillent (parfois) sur ce principe http://www.codes-libres.org/visual/spip.php?rubrique501
