Hiérarchie unique ou multiple ? les deux !
Une unique rubrique, sinon c’est le bazar !
Par défaut, SPIP ne permet qu’une hiérarchie simple, qui consiste à associer chaque élément éditorial à un unique parent. Ceci résulte d’une volonté de contraindre le webmestre à structurer son site sainement.
En effet, le besoin de faire apparaître un contenu à deux endroits du site relève souvent d’une classification pas aboutie et d’une navigation mal pensée. Contraindre le webmestre à choisir une unique rubrique l’oblige donc à un minimum de réflexion sur l’arborescence du site, et évite la tentation des liens transverses multiples qui conduisent rapidement au capharnaüm.
Ainsi par défaut, SPIP ne permet de fabriquer que des sites bien rangés, avec une arborescence dont la hiérarchie stricte permet de ne pas se perdre.
Mais la polyhierarchie, c’est bien utile...
On parle de polyhierarchie [1] dès lors qu’un contenu est rattaché à plusieurs parents.
Il est parfois impossible de classer certaines données en arborescence, tel que le propose SPIP, sans perdre beaucoup en terme de compréhension ou de navigation. Pour illustrer un tel besoin, on peut lire les discussions sur la catégorisation hiérarchique dans Wikipedia qui en arrive à la conclusion que les liens hiérarchiques n’ont pas leur place dans une encyclopédie digne de ce nom
, ou apprécier le cas, plus trivial, du classement de recettes de cuisine qui sont liées chacune à plusieurs ingrédients, à plusieurs type de plat, etc.
Dans ces cas-là, l’arborescence stricte imposée par SPIP est une limite gênante et les contournements habituellement utilisés (article virtuel, alias d’article, recopie de l’article) sont plus ou moins adaptés, plus ou moins pratiques et souvent lourds à l’usage.
Principe du plugin polyhierarchie
Le plugin permet de créer des liens hiérarchiques transversaux en rattachant articles et rubriques à plusieurs rubriques.
Dans la base de données, chaque article et rubrique conserve son unique parent principal, ce qui permet de désinstaller le plugin sans dommages pour le site.
Les liens secondaires vers les autres rubriques sont stockés dans une table annexe. Ils sont utilisables via des critères de boucle spécifiques.
On peut donc parler, pour chaque objet
- d’une arborescence principale, qui permet d’accéder le plus directement au contenu. On appellera "liens directs" les liens qui constituent cette arborescence principale. Ce sont les liens en trait continus sur l’exemple ci-dessus.
- d’une ou plusieurs arborescences complémentaires ou secondaires qui permettent d’accéder au contenu de façon indirecte. On parlera de liens indirects. Ce sont les liens en traits pointillés sur l’exemple ci-dessus.
Les termes « direct » et « indirect » seront utilisés dans les critères pour distinguer les deux types de liens pour les parents et les enfants.
En résumé, on peut retenir que les liens directs constituent l’arborescence principale de SPIP, qui est maintenue, même en l’absence du plugin. Les chemins secondaires constitués des liens indirects sont des navigations complémentaires ou transversales, qui ne seront utilisables que si le plugin est actif.
Utilisation dans l’espace privé
Dans l’espace privé, l’arborescence principale reste la référence. Mais les liens indirects permettent des navigations transversales utiles pour l’organisation du site.
Édition d’un article ou une rubrique
Lors de l’édition d’un article ou d’une rubrique, le sélecteur de rubrique par défaut est remplacé par un système de sélection multiples.
La première rubrique de la liste est celle de l’arborescence principale. Les suivantes constituent l’arborescence secondaire. Il est possible de changer l’ordre des rubriques par simple glisser-déplacer pour modifier la rubrique parente directe.
Le lien « ajouter » permet de faire apparaitre le navigateur de rubrique pour sélectionner une rubrique supplémentaire.
Il suffit de cliquer sur le « + » en regard d’une rubrique pour l’ajouter aux parents sélectionnés.
Le champ « Ajout rapide » permet d’indiquer un id_rubrique pour l’ajouter sans chercher dans l’arborescence. Il suffit d’entrer rubX (où X est l’id_rubrique) dans le champ et de cliquer sur Ajouter.
Chemins secondaires
Lorsqu’un article a plusieurs parents, le chemin affiché en haut est celui qui constitue l’arborescence principale. Les parents indirects sont également listés après la mention « Egalement dans les rubriques ».
Les liens permettent d’aller vers ces rubriques parents secondaires.
Contenus secondaires d’une rubrique
Dans une rubrique qui contient des enfants indirects, ceux-ci sont listés dans la marge latérale.
Comme précédemment, les liens permettent de naviguer vers ces contenus secondaires pour les modifier.
Utilisation dans les squelettes
L’utilisation de la polyhierarchie suppose que les squelettes soient conçus pour gérer les possibilités de navigation transversales. Pour cela, le plugin mets à disposition du webmestre plusieurs critères permettant de naviguer dans les arborescences multiples.
La boucle HIERARCHIE
La boucle HIERARCHIE n’est pas modifiée. Elle permet donc de dérouler le chemin principal d’une rubrique.
Le critère {branche}
Le critère {branche} est étendu. Il englobe par défaut les éléments liés indirectement aux rubriques de la branche, mais sans parcourir les rubriques enfants indirectes.
Dans une boucle RUBRIQUES, les rubriques rattachées indirectement à la branche directe seront donc inclues, mais pas parcourues (leurs enfants ne seront donc pas inclus)
<ul>
<BOUCLE_branche2(RUBRIQUES){branche #ID_RUBRIQUE}>
<li>#ID_RUBRIQUE-#TITRE</li>
</BOUCLE_branche2>
</ul>
Appliqué à la rubrique d' du schéma ci-dessus, le critère {branche} donnerait donc la liste b, g', f', h, e
Dans une boucle ARTICLES, les articles rattachés indirectement sont inclus, mais pas les articles enfants d’une rubrique rattachée indirectement.
Par ailleurs, l’écriture {branche #ID_RUBRIQUE} est acceptée.
Le critère {branche_complete}
Le critère {branche} est donc complété par un critère {branche_complete} qui inclut cette fois tous les contenus trouvés en parcourant toutes les branches principales et secondaires.
<ul>
<BOUCLE_branche_complete3(ARTICLES){branche_complete #ID_RUBRIQUE}>
<li>#ID_ARTICLE-#TITRE</li>
</BOUCLE_branche_complete3>
</ul>
Appliqué à la rubrique d' du schema ci-dessus, le critère {branche_complete} donnerait donc la liste b, g',a, c, f', h, e
L’écriture {branche_complete #ID_RUBRIQUE} est acceptée.
Le critère {branche_principale}
Symétriquement, le critère {branche_principale} permet de réduire la sélection aux éléments de l’arborescence principale uniquement. Ce critère permet donc de retrouver les enfants de la branche principale classique de SPIP.
Appliqué à la rubrique d' du schéma ci-dessus, le critère {branche_principale} donnerait donc la liste g', f', h, e
Le critère {enfants}
Il permet de sélectionner les enfants d’une rubrique. Il peut s’utiliser sur une boucle RUBRIQUES, ARTICLES, ou tout autre boucle contenant un champ id_rubrique, même si la polyhierarchie ne s’y applique pas.
Il peut s’écrire {enfants} et prendra alors l’#ID_RUBRIQUE dans le contexte ou dans la boucle englobante, ou explicitement {enfants #ID_RUBRIQUE} ou encore {enfants #LISTE{12,23,36}} pour cibler plusieurs rubriques.
Appliqué à la rubrique d' du schéma ci-dessus, le critère {enfants} donnerait donc la liste b, g'
Le critère {enfants_directs}
Il fonctionne comme le critère {enfants}, mais permet de restreindre la sélection aux enfants directs.
Appliqué à la rubrique d' du schéma ci-dessus, le critère {enfants_directs} donnerait un seul résultat g'
Le critère {enfants_indirects}
Il fonctionne comme le critère {enfants}, mais permet de restreindre la sélection aux enfants indirects.
Appliqué à la rubrique d' du schéma ci-dessus, le critère {enfants_indirects} donnerait un seul résultat b
Le critère {parents}
Il permet de sélectionner les parents d’une rubrique, d’un article, ou de tout autre contenu. Il ne peut s’utiliser que sur une boucle RUBRIQUES.
Il peut s’écrire {parents} et fait référence à l’élément de la boucle englobante, ou {parents #GET{id_rubrique}} et fait référence à la valeur passée, ou {parents #LISTE{12,23,36}} .
Appliqué à la rubrique b du schéma ci-dessus, le critère {parents} donnerait donc la liste d, d'
Le critère {parents_directs}
Il fonctionne comme le critère {parents}, mais permet de restreindre la sélection aux parents directs (un seul dans la pratique !)
Appliqué à la rubrique b du schéma ci-dessus, le critère {parents_directs} donnerait donc la liste d
Le critère {parents_indirects}
Il fonctionne comme le critère {parents}, mais permet de restreindre la sélection aux parents indirects.
Appliqué à la rubrique b du schéma ci-dessus, le critère {parents_indirects} donnerait donc la liste d'
Publication des rubriques
Par défaut, dans SPIP, une rubrique n’est visible dans l’espace public et dans les boucles que si elle contient des objets publiés.
Avec polyhiérarchie, à partir de la version 0.3.0 du plugin, si une rubrique ne contient aucun contenu direct, mais des articles ou rubriques indirects publiés, la rubrique sera alors publiée et visible dans l’espace public.
Pour résumer
Le plugin met a disposition tous les outils pour concevoir et développer avec SPIP des sites faisant appel à la polyhiérarchie.
Cela peut aller de simples cas où les articles sont ponctuellement présent dans une seconde rubrique, à des cas complexes faisant un usage avancé de la polyhierarchie.
Dans tous les cas, il convient de bien réfléchir préalablement à la classification des données du site, et de ne pas se précipiter dans une organisation approximative au prétexte que le plugin permet ensuite de faire des liens transversaux.
Le plugin met a disposition des outils et des possibilités, mais c’est au webmestre de veiller ensuite à l’usage qui en sera fait !
Et après ?
Cette première version du plugin a pour but d’évaluer le concept et les limites qu’il faudra lui poser éventuellement.
En fonction des usages il pourra être utile d’enrichir le plugin avec des possibilités de configuration (par exemple pour ne permettre la polyhierarchie que sur les articles), ou des contrôles de sécurité (par exemple ne pas mettre un contenu dans une rubrique et dans sa parente, ne pas créer de navigation circulaire ...).
Discussions par date d’activité
97 discussions
Hello,
Je ne comprends pas bien l’argumentation développée pour justifier l’utilité du plugin.
D’abord dans la partie « pourquoi ce plugin », tu cites l’exemple de wikipedia qui dit
Et dans la partie « que fait le plugin » tu dis :
L’exemple elliptique de cuisine libre n’est pas tellement plus probant, scientifiquement parlant.
Cela étant posé, en lisant entre les lignes, je comprends qu’il s’agit en fait de pouvoir classer un contenu dans plusieurs arbos. C’est à dire comme les mots clés arborescents, mais implémenté ici sur la techno des rubriques pour aller vite.
Alors puisqu’on discute, voici mon avis : je crois que c’est le concept plutôt de rubrique qui vieillit, plus que celui de mots clés.
En résumé, nous voilà fasse à un chouette plugin, qui va permettre d’attendre le vrai plugin mots clés arborescents, type taxonomie dans Drupal.
Le concept du rubrique qui est dépassée ? Faut pas exagérer quand même. C’est pas parce qu’il y a une envolée des sites fourre-tout où tout le monde rajoute son contenu (cad sans ligne éditoriale précise) et où là effectivement, un système de mots-clés est plus approprié, que les rubriques sont mortes.
Espèce de progressiste !
Dans la majorité des cas, un système hiérarchique de rubrique est largement suffisant pour classer des objets, mais surtout largement supérieur intellectuellement parlant pour que le cerveau retrouve facilement un objet qu’il cherche.
Le tout, comme l’a dit Cédric c’est d’arriver à permettre plusieurs types de classements avec la même implémentation derrière, pour que techniquement ce soit facilement maintenable et facilement compréhensible pour les devs et pour ceux qui ajoutent le contenu.
Reprenons l’exemple passionnant, car inépuisable, des recettes de cuisine : la recette des « carottes râpées à l’échalote » doit être rangée dans « carotte » ET dans « échalote » (eux-mêmes dans « légumes »), ainsi que dans « entrée » ET « salade », ainsi que dans « végératien » ET « végétalien » (ce dernier étant une sous-catégorie du précédent), etc. Un tel classement peut, bien évidemment, être réalisé avec des mots-clefs, de préférence arborescents, comme toutes les autres catégorisations propres à cet exemple (types de plat, régime alimentaire, niveau de difficulté, saisons, etc.)
Ce faisant, toutes les recettes se trouvent correctement étiquetées de mots-clés, mais en vrac, dans une énorme rubrique « recettes » (puisqu’il est obligatoire, dans SPIP, d’avoir au moins une « rubrique »)...
Il est alors nécessaire de choisir une des catégorisations comme principale, ne serait-ce que pour pouvoir proposer une navigation principale sur le site public. Cela n’est actuellement pas possible avec les « mots-clés » de SPIP, mais depuis toujours correctement réalisé par les « rubriques » de SPIP.
Ceci dit, puisqu’il semble falloir choisir entre les deux, mon avis est que « mots-clefs » ou « rubriques », on s’en fiche, pourvu qu’il soit possible de catégoriser vraiment le contenu, ce qui nécessite parfois de dépasser leurs limites respectives et de combler leur manques, car bien que deux, « mots-clefs » et « rubriques » ne font jamais que ce que l’autre ne fait pas, là où un seul type d’objet aurait suffit à tout faire. Ainsi pourrait-on en débattre longtemps...
@tetue :
Tu confonds la fonction (rangement anti-vrac) avec l’organe (rubrique). En conséquence, tu considères que si on remplaçait le classement en rubriques par un classement avec des motclés... on ne changerait par contre pas le classement en rubrique pour les usages de rangement !
Mais si on remplace le rangement en rubriques par l’usage de motclés arborescents, oui, il n’y a plus qu’une seule rubrique où tout est en vrac, mais alors l’usage de ’rangement’ des rubriques doit être remplacé par un groupe de motclés dédiés - refaisant ce qu’on faisait avec les rubriques, et ci, y compris dans la partie privée.
Exemple : Si l’arborescence des rubriques (n’existant plus) était décrite par l’arborescence issue d’un groupe de motclés appelé ’rubriques’, par exemple, il suffirait que la partie privée de spip utilise ce groupe réservé pour proposer une navigation privilégiée et hop, on aurait plus ce bordel horizontal que tu décris.
En plus, il pourrait y avoir plusieurs navigations privilégiées sélectionnables. Ce pourrait être une option des groupes de motclés « Oui/Non : Pouvoir se servir de ce groupe de motclé comme d’une navigation entre les objets ». Et on pourrait dans la partie privée sélectionner selon quel groupe de motclé doit être le mode de navigation privilégié (proposé par la partie privée de spip).
Heu je comprends pas la logique....
Tu propose donc de rendre les mots clés arborescents et de refaire toute la navigation de l’espace privé en fonction d’un des groupes de mots clé.
Ce n’est pas plus simple de renommer les rubriques ’mot clé’ à ce compte là ? Qu’est-ce que tu veux faire avec les mots clés arborescent que tu ne peux pas faire avec les rubriques polyhierarchiques ?
@Cédric : Ce n’est pas une proposition, mais une discussion. Je cherche la justesse dans le débat et je corrige @T en précisant ce que ça pourrait être avec des motclés arborescents et comment ça ne génèrerait pas de vrac mais au contraire des organisations et rangements parallèles.
Si on renommait les rubriques polyhiérarchie en « motclés » comme tu le suggères, on aurait presque la même chose en effet, à la différence près qu’avec la polyhiérarchie du plugin, il y a par conception une arborescence principale et les autres secondaires, et des boucles différentes pour les interroger, alors que tous les groupes de mot-clés sont par défaut au même niveau.
La limitation c’est que la polyhiérarchie des rubriques se traduit donc dans l’interface privée ET publique par une navigation principale et des navigations auxilliaires.
- Dans l’interface privée, c’est le plugin qui fixe les choses ainsi.
- Dans l’interface publique, c’est fortement induit ainsi puisque ce ne sont pas les mêmes boucles pour interroger l’une ou les autres, mais il est je pense possible de concevoir quand même « comme on veut » une équivalence apparente des hiérarchie.
Ceci dit, cela n’enlève rien à l’intérêt de ce super plugin qui apporte quelque chose d’attendu depuis longtemps !
Cela correspond peut être à l’état historique majoritaire de conception de la réalité, et c’est rassurant pour aborder la création de contenu. Juste c’est un peu limitant aussi en nos époques ... ’post-modernes’ ?
En effet, ce joli plugin me semble être une solution d’attente en vue d’un plugin (ou d’une fonctionnalité native de SPIP) de mots-clés arborescents et attachés à tous les objets de SPIP. L’attribution de mots-clés aux auteurs est par ailleurs, et curieusement, un vieux serpent de mer qui a fait couler beaucoup d’encre.
En tant qu’utilisateur, je recherche depuis longtemps à associer une région et un département à un auteur via un système de mots-clés arborescents. Pas sûr, comme le laissait entendre Cédric, que le plugin polyhiérarchie permette cela facilement.
Enfin, mon regard profane comprend mal pourquoi l’arborescence est si difficile à mettre en oeuvre sur les mots-clés alors l’arborescence des rubriques existent depuis la nuit de SPIP !
En tout cas, bravo aux auteurs !
Mais arrêtez avec cette histoire de noms différents à la fin !
Le plugin Polyhiérarchie propose déjà ça. Peu importe que le nom donné à l’élément de classification soit le mot « rubrique » ou le mot « mot-clé ». Vraiment.
Techniquement les mots de SPIP sont un vrai bazar puisqu’il y a une table de liaison de créée pour chaque objet auquel on veut lier des mots. Hors le plugin Polyhiérarchie a été développé directement avec la même solution que ce qui existe déjà pour les documents : une seule table de liaison où l’on met l’id de la rubrique, le type de l’objet et son id.
Ce qui signifie que l’on peut dors et déjà lier les auteurs ou n’importe quoi d’autre à des rubriques de la polyhiérarchie ! Ce n’est qu’une question d’interface pour le faire, techniquement c’est déjà possible.
Le seul truc qui manque pour l’instant, ce sont les options que l’on trouvaient dans les groupes de mots pour restreindre l’utilisation d’un secteur à tel type de compte (admin, rédac, visiteur), à tel type d’objet (ce secteur ne peut être lié qu’avec des articles/documents/auteurs/etc), obligatoire ou pas (pour forcer le choix d’une rubrique de ce secteur). Bref comme pour les mots.
Et c’est bien évidemment plus simple d’ajouter ces options au plugin polyhiérarchie, que d’ajouter l’arborescence et les liaisons à tout type d’objets aux mots.
Ah oui, mais alors dans le « concept » ce sont des mots polyhierarchiques, qui choppent leur propriété arborescente sur les rubriques par opportunisme, plutot que sur des groupes de mots qui ne sont pas aujourd’hui arborescents :p.
Est-ce que ca vaudrait le coup d’envisager des groupes de mots arborescents, et des mots liés a tout avec une table de jointure comme les documents ?
On garderait comme ça le distinguo important à mon sens pour l’ergonomie et l’efficacité :
Rubrique -> ranger
Mots-clés -> décrire / trouver
Répondre à ce message
Aujourd’hui sur spip, l’organisation du contenu est mono logique = un seul sens de lecture, défini par le(s)responsable(s) éditorial(aux).
L’avancée : permettre au lecteur de s’approprier le contenu selon sa logique. Requière une navigation transversale.
En ce sens ce plugin répond à un vrai besoin. Merci aux auteurs.
Ces autres chemins de navigation peuvent être définis par les ontologies (taxonomie drupal vue ci-dessous ?). J’attendais de mettre cela en application avec les mots clés et je n’étais pas loin de partager cette réflexion de Booz ci-dessous : la rubrique est dépassée. Je suis d’accord avec l’homme à la cravache et au monocle, elle suffit et répond très bien à organiser un site dont le contenu est bien balisé. Mais très vite lorsque le volume d’information est important (tendance lourde de notre époque), trouver l’information quand on en est pas l’organisateur peut se révéler complexe (voir les nombreuses rubriques de Clubic). On aimerait dans ces cas là au moins une recherche multicritère, en associant des mots clés, en les filtrant (voir la page powersearch d’IMDB pourtant pas avant gardiste), et encore mieux, des suggestions en fonction d’un mot tapé, genre plugins étiquettes- (merci rastapopoulos)- nuage -sélecteur générique - snippets). Pour cela, il faut avoir structuré et qualifié le contenu du site avec des ontologies. Vous avez dit Linked data, web sémantique ?
Alors le roi est mort ? Pas vraiment. Car l’héritier légitime le mot partout, même arborescent, même sous spip 2, ne permet pas encore d’associer un mot clé à un autre mot clé. Id parent reste l’apanage du groupe de mot. Logique mono hiérachique pyramidale. Bye bye ontologie, on garde les thésaurus et le champ « rechercher sur ce site ».
Le roi n’est pas mort, il se porte mieux même. Merci pour la cure de jouvence et les nouvelles possibilités offertes. Pour autant, mis de côté l’aspect maintenance du code, le plugin offre t il autant de possibilité que ce que laisse entrevoir le prometteur mot clé - vraiment - partout et arborescent de zerax ? Et je me pose la question de la dispersion d’énergie.
oublie les dénomination de rubrique et mot-clé, et réfléchis au niveau fonctionnel. En creusant, tu verras vite que tout ce que tu voudrais faire avec des mots-clés arborescent peut se faire au moyen d’une polyhierarchie. Avec une économie de moyen que le temps montrera, mais que j’ai pu constater...
oui, a priori bien d’accord avec vous deux (Romy Cédric) : qu’importe la dénomination, pourvu que l’horizon soit vaste. Le besoin fonctionnel est bien le même. C’est d’ailleurs compatible avec la vue heuristique citée ci-dessous (mind mapping) et qui m’est chère. A ce sujet Eric Luyckx, voir l’excellent plugin Afficher la zone. Donc j’applique et je vous dis quoi.
Répondre à ce message
Salut à toutes et tous
j’ai l’impression qu’on tient le bon bout ! d’autant que moi ce qui m’interesserait c’est une polyhierarchie… de mots-clef.
Je m’explique : pouvoir associer un mot-clef à plusieurs groupes ou sous-groupes de sorte à pouvoir organiser les mots-clef comme un mind-mapping (à l’instar de l’icône du plugin ;-)
intérêt ? une indexation complexe arborescente nécessite une connaissance approfondie du thésaurus. une organisation en carte heuristique permet un cheminement naturel vers le bon mot-clef via des trajectoires (fil d’ariane) différentes et qui correspondent respectivement mieux à chaque ’encodeur’… et à chaque visiteur
bref je ne sais pas si le travail est transposable sur les mots-clef, je présume qu’à part la nomenclature des tables et de quelques champs, il n’y aurait pas grand chose à modifier.
encouragements anyway
Eric
Le code n’est pas transposable aux mots-clés. La preuve en est la difficulté à faire emerger la fonctionnalité de mots-clés arborescents.
peut-être. le problème de mots_partout (outre son instabilité) c’est qu’il reste dans une logique arborescente…
au niveau rédactionnel, je rejoins qqn du forum qui soulignait la facilité naturelle que représente l’arborescence de base pour le quidam qui vient rédiger ses premiers articles. la distinction à ce niveau (purement culturelle et ergonomique) reste intéressante.
Répondre à ce message
Trop génial ce plugin...
Je bute sur un problème pratique quand j’essaye d’installer le plugin -
Message d’erreur :
Impossible d’activer le plugin auto/polyhierarchie
* Nécessite le plugin SPIP_BONUX en version [1.8 ;] minimum.
Alors que j’ai bien Spip Bonux 2.0 installé et activé ....
Télécharge le dernier zip de bonux, réinstalle le, et ça ira mieux !
Yep, ça le fait, je m’y plonge... Merci :-)
Je viens de faire quelques tests de charge serveur sur un bon serveur et un site un peu costaud (beaucoup de rubriques, beaucoup d’articles) pour une même rubrique
1/ id_rubrique 2/ branche complete #ID_RUBRIQUE 3/ enfants #ID_RUBRIQUE
Voici ce que ça donne en comparaison :
1/ 0.244152162613
2/ 2.20104440564
3/ 0.81874920459
Est-ce qu’il y moyen d’optimiser la charge à part de se limiter à l’option 3 et/ou de faire un squelette particulier pour certaines rubriques, ce qui revient à créer de la complexité ?
Sinon, je confirme et signe toujours trop génial la polyhiérachie :-)
le critère
{branche}est lent car il necessite plusieurs requetes consécutives pour parcourir la descendance de façon recursive.Ce n’est pas lié à la polyhierarchie, mais à la modélisation interne de l’arborescence dans SPIP, qui repose sur un simple pointeur sur le parent.
Il y a des méthodes de représentations des graphes plus efficaces, mais il faut les implémenter au niveau de la table des rubriques. Ca n’a pas été prioritaire jusqu’ici. C’est surtout délicat car il faut blinder la migration, tester, valider etc ..., l’erreur et la perte éventuelle d’arbo n’étant pas permises !
Je vais surveiller un peu la charge globale du serveur - le cache devrait éviter le pire. Après pour amener Spip à être encore plus souple pour de très gros sites, je suis fan et je le serai tous les jours un peu plus ;-)
Répondre à ce message
Bonjour,
Merci pour ce plugin intéressant. Je le commente ici :
http://icp.ge.ch/sem/cms-spip/spip.php?article818
SPIP exploite justement les mots-clés et famille de mots-clés pour suppléer à ces insuffisances. Ainsi, les mots clés dans SPIP sont conçu pour créer des navigations transversales complémentaires à la navigation naturelle dans l’arborescence des rubriques. Ce qui donne généralement pleine satisfaction.
De plus, zerax a créé un plugin pour des arborescences de mots-clés :
ou gestion des mots clés avec un principe d’arborescence
dimanche 23 septembre 2007, par zerax
http://www.spip-contrib.net/mot-clefs-partout
Il permet d’utiliser les mots clefs dans une structure en arborescence. Il permet aussi d’ajouter facilement les mots clefs sur les documents.
Ainsi, ce nouveau plugin Polyhiérarchie va nourrir notre réflexion et peut-être notre pratique, en ce sens que maintenant nous pouvons réfléchir à des stratégies de navigation qui exploitent quatre concepts complémentaires :
Meilleurs messages
FDG
Je réponds ici aux remarques que tu fais dans ton article.
Tu note notamment que nous avons omis de citer les mots clés comme solution à la navigation transversale. Il est vrai que nous n’avons pas développé toutes les solutions qui ne marchent pas (ce n’était pas vraiment le but de l’article), mais les exemples cités ne peuvent être résolus non plus de manière satisfaisante avec les mots clés de SPIP.
Ensuite, tu évoques la possibilité existante des mots clés arborescents. Effectivement, ce type de fonctionnalité, tel le serpent de mer va et viens au gré des contrib (au temps de la 1.8) ou plugin plus ou moins à jour.
La vrai question à poser, à mon sens, est : quand on en arrive à rattacher un objet à 2 ou plusieurs arborescences, pourquoi devrait-on utiliser 2 types d’objets différents pour modéliser ces arborescences ? Je ne vois aucun avantage à cela, et que des inconvénients :
Pour aller jusqu’au bout de ma pensée, les mots-clés de SPIP sont un concept batard.
Il faut laisser le temps juger à l’épreuve des faits, mais il me semble que SPIP serait plus efficace (tant du point de vue des codeurs avec plein de code compliqué en moins, que du point de vue des utilisateurs) avec d’un côté une polyhierarchie des rubriques, et de l’autre un objet de type tag très léger et simple.
Répondre à ce message
je travaille actuellement sur accès restreint
je suppose que la hiérarchie des zones n’est pas cassée par cet apport ?
Le plugin accès restreint continuera à fonctionner sur les arborescence principales uniquement, effectivement.
Répondre à ce message
Simple question pour information : quel(s) avantage(s) ce plugin apporte-t-il par rapport à l’utilisation de mots-clefs que l’on dédierait à cet usage ?
Les « mots-clefs » de SPIP ne sont pas arborescents, les rubriques oui. Avec ce plugin, plus besoin de ces « mots-clefs », puisque la navigation transversale peut-être réalisé avec des rubriques supplémentaires liées aux articles.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
