Projets « Suggestions de fonctions « Sections «

Une page est une page est une page

4
votes

Pour en finir avec la distinction Section-Article-Catégorie-Commentaire

En fait le sous-titre ci-dessus est nettement exagéré et il ne s'agit pas de supprimer la distinction entre article, section, catégorie, etc., mais bien de la gérer autrement.

Je regroupe ici, pour mémoire et pour analyse, diverses pages qui traitent du sujet, dont la plus récente date de ce matin (25 mars 2010) et la plus ancienne (que j'aie retracée) du 24 mai 2007 :

Ce pourrait être une bonne idée, pour la prochaine version majeure de Yacs, de s'attaquer enfin au « serpent de mer », comme l'a surnommé Tof.

Alexis Raimbault -

a noter, la difference entre section et article est parfois utilisé par le thème. Par exemple "digital" modifie sa colonne extra en fonction du type de page affichée.

Alexis Raimbault webmaster free-lance

Jmarc -

Pour éviter de chambouler l'existant mais pour commencer à s'attaquer "au serpent", ne pourrait-on pas envisager de créer un nouveau type de page (encore un ! ) que l'on intitulerait tout simplement "page" et qui regrouperait tous les champs et les fonctionnalités des autres types de page (section, article, catégorie,etc...) ?

Un champ "type" pourrait même continuer de mémoriser la fonction de la page (section, catégorie, article, etc...) afin de pouvoir, par exemple, adapter le skin au type de page.

Coté associé, on aurait un site yacs qui n'est qu'une grande arborescence de pages que l'on spécialiserait à la demande en changeant leur type

Que la vie serait belle ...

Alain Lesage -

En relisant le post inital de Tof (Définition d'une entité mère aux sections, articles, etc...), je vois que Bernard était d'accord avec le principe suggéré par Tof mais il recommandait d'attendre « que ça gratte ». Et bien, peut-être que ça gratte suffisamment maintenant...

Le principe suggéré par Tof était de créer une classe Entity qui pourrait être étendue par les classes Sections, Articles, etc et contiendrait les fonctions communes.

Sans être programmeur, je crois que ça rejoint l'idée de Jmarc ci-dessus, tout en généralisant le principe.

Ainsi, même une image ou un fichier attachés constitueraient des extensions de la classe Entity (puisqu'ils ont déjà des descriptions et d'autres fonctions des pages).

Pour continuer à élaborer sur cette idée, j'imagine que le "type" donné à chaque page (ou entité) pourrait non seulement aider à préciser son affichage mais également son mode de rattachement dans l'arborescence.

Une entité de type Section pourrait se voir rattachées des entités de types Section (ses sous-sections), Article, Comment, Image, File, etc.. Un skin ou un layout pourrait gérer l'affichage des entités attachées, en plaçant par exemple les articles en listes sous la description et les commentaires en onglet (on peut déjà faire ça) ou en créant des onglets pour chaque sous-section (on n'a pas encore ça que je sache).

Pour transformer un article en section ou inversement, il suffirait de changer son type. Pour promouvoir un commentaire, il suffirait de modifier son type Comment en Article. Inversement, on pourrait facilement transformer un article en simple commentaire par changement du type.

Au risque de créer le chaos dans un site, on pourrait même imaginer que le rattachement ne se fasse pas uniquement de façon arborescente mais également réticulaire (en réseau), en permettant qu'une même entité soit rattachée simultanément à plusieurs autres. Ne serait-ce pas là une voie à explorer en rapport avec les questions de stockage d'images récemment soulevées ?

Christophe Battarel -

Alain Lesage : en fait il y a déjà des classes Anchors et Anchor dont dérivent les classes articles, sections, etc... pas besoin donc d'écrire une nouvelle classe Entity, donc.

Par contre, cela reste un sacré boulot de faire tout ce qu'on imagine...

Christophe Battarel - Société altairis -

Jmarc -

Alain a suggéré :

" Pour transformer un article en section ou inversement, il suffirait de changer son type. Pour promouvoir un commentaire, il suffirait de modifier son type Comment en Article . "

clap

" on pourrait même imaginer que le rattachement ne se fasse pas uniquement de façon arborescente mais également réticulaire (en réseau), en permettant qu'une même entité soit rattachée simultanément à plusieurs autres. "

re- clap