Bonjour
Avant de passer à Drupal j'ai beaucoup utilisé un CMS qui s'appelle Modx qui reste pour moi au niveau logique une référence; et depuis quelques temps me trotte dans la tête de reprendre quelques uns de ces concepts clefs et de les insérer dans drupal via des nouveaux modules. Ce que j'aimerai voir dans drupal :
-> une arborescence comme dans Modx : En langage drupal ça signifierait que n'importe quel node peut avoir pour enfant n'importe quel node; ainsi à l'infini. Ainsi le node parent devient en réalité une "rubrique" au sens véritable du terme, ce que ne permet pas la taxonomie à mon sens. Le fait de créer des liens parents enfants n'a rien de nouveau; en revanche je n'ai trouvé aucun module qui m'ont permis de réellement envisager ça comme un véritable systeme de rubrique.
-> Il devrait exister un bloc menu capable de générer automatiquement le menu des rubriques en fonctions des parents/enfants (un node est une rubrique si il contient des enfants, on parcourt de façon récursive et paramètrable l'architecture parent/enfant)
-> Un module de breadcrumb devrait aussi être généré sur cette base.
En fait je n'ai besoin de la taxonomie que pour des classements et recoupements, mais pour organiser un systeme de rubriques cohérent et logique, je reste très déçu de ce systeme.
Bien sûr il y a beaucoup d'objections à faire et on peut retrouver des idées de modules existants (context).
Mon principal souci serait la possibilité d'avoir un systeme de rubrique très classique "genre à la 'spip' excepté qu'une rubrique serait un node drupal avec toutes les possibilités que ça implique.
Enfin il serait intéressant de générer automatiquement une page qui reprend les principales rubriques, avec leur images et un lien "ajouter un article" que ce soit pour l'admin d'un client ou les membres d'un site.
Qu'en pensez vous, idiot, déjà fait, à réfléchir?
J'ai des connaissances en php et je cherche éventuellement quelqu'un pour m'aider à réfléchir à tout cela, voire à programmer qui sait.
Comments
Books ?
Quel serait fonctionnellement la différence avec le module Books qui est dans le Core ?
Je suis drupal 5 et le
Je suis drupal 5 et le module book était beaucoup moins avancé que sur drupal 6 apparemment. Je ne l'ai pas encore testé à fond sur drupal 6. L'idée est simplement de renforcer la notion de rubrique et d'arborescence et de se baser dessus pour la construction du site. Il me semble aussi que le module book est orienté wiki. C'est surtout en terme d'ergonomie d'installation et de présentation que je voudrais quelque chose de plus robuste; pas simplement au niveau du schema de la BDD relationnelle.
En fait il y a beaucoup de modules qui font chacun une partie ce que j'ai dit : module book, context, sections, panels... Mon idée est juste de renforcer la notion de rubrique (que je trouve étrangement quasi absente du vocabulaire de Drupal) de façon très simple et claire.
Je testerais plus à fond drupal 6 avant d'en dire plus, mais il est clair que sur Drupal 5 cette notion est trop faible à mon sens.
Bonjour, Le plus simple est
Bonjour,
Le plus simple est probablement de passer à D6 - je n'ai plus exactement en tête les manques dont tu parles dans D5... mais tout ce que tu décris est assez basic et ne pose pas de problème : entre book et views, tu disposeras des fonctionnalités souhaitées.
Pour passer à une présentation Menu, il te faudra peut-être faire un peu de CSS - tout dépend de ce que tu souhaites exactement.
Alexandre ISRAËL
Bloggy Business - http://bloggybusiness.com
Alexandre ISRAËL
Bloggy Business - http://bloggybusiness.com
Hello Ok, j'en reparle dans
Hello
Ok, j'en reparle dans une semaine quand j'aurais testé drupal 6 plus à fond et surtout le module book qui m'avait laissé sur ma faim pour plusieurs raisons que j'ai un peu oubliées entre temps. Je pense que ceux qui ont testé Modx comprendront un mieux mon ressenti quant au manque de limipidité de la structrure d'un site drupal. Je reviendrai sur ce post avec quelque chose de plus concret bientôt ;-)
Mon petit grain de sel :)
Bon comme je connais très bien MODx et que je commence aussi à bien connaître Drupal... je vais donner mon avis.
Le module Book ne correspond pas à l'arborescence dans MODx à mon avis car il ne permet pas de gérer une arborescence pour l'ensemble des types de contenu (ou alors j'ai raté un truc).
Le module le plus proche de la structure hiérarchique de MODx est Node Hierachy. En effet celui-ci permet de gérer la relation parent/enfant, de fournir une arborescence similaire à ce qu'on trouve dans des CMS organisés autour de la notion d'arborescence. Il permet en plus, comme tu le souhaite Nyl de créer automatiquement des éléments de menu, de tenir compte de la hiéarchie pour la génération du fil d'ariane (il me semble) et surtout des alias.
Après avoir pas mal expérimenter avec NodeHierarchy, je suis partagé : sur le papier, c'est exactement ce que je cherchai (et les options dispo sont pertinentes et même plus puissante que celles offertes par MODx) mais l'implémentation pose quelques problèmes :
- le js de l'arborescence est lourd et plante souvent, j'ai même hacké le module pour éviter purement et simplement de charger le js. C'est un énorme point faible pour un module qui vise à apporter une gestion hiéarchique des contenus.
- il y a des incompatibilités notamment avec Book et Forum : ça peut être problématique...
Un des trucs qui désoriente le plus les utilisateurs dans Drupal c'est l'absence de hiérarchie. Pour ceux qui ne travaillent pas avec des clients, je peux comprendre qu'on se demande où est le problème. L'arborescence est plus linéraire mais rassurante car on sait "où" se situent les contenus. Il faut bien comprendre que l'utilisateur final n'a pas réellement de compréhension de ce qu'est un site dynamique, sa perception du CMS est celle de la page telle qu'elle est générée au final, avec un emplacement "physique" qui est l'adresse de celle-ci. C'est ce qui explique que j'ai beaucoup moins besoin d'expliquer lorsque je bosse avec MODx qu'avec Drupal.
Cette parenthèse mise à part, ma conclusion par rapport à Node Hierachy est qu'il est très difficile de "plaquer" un concept alternatif à celui que le core de Drupal a adopté. Drupal est un CMS non-hiérarchique et par conséquent la vaste majorité des modules sont calés sur ce paradigme et ne seront jamais "connectés" avec Node Hierarchy. Cela affaibli énormément l'intérêt du module. Il faudrait que NodeHierachy réussisse le tour de force de s'imposer comme Views ou CCK afin que de multiples modules "supportent" ses fonctionnalités. Mais je ne suis pas sûr que ce sera le cas à l'avenir...
N'importe quel type de
N'importe quel type de contenu peut-être ajouté dans une structure de livre... :-)
Il faut aller dans les paramètres de Book pour choisir les CT qui vont bien.
Bonne exploration.
Alexandre ISRAËL
Bloggy Business - http://bloggybusiness.com
Alexandre ISRAËL
Bloggy Business - http://bloggybusiness.com
Oui on peut ajouter
Oui on peut ajouter n'importe quel type de contenu mais à l'époque quelque chose m'avait tout de même arreté sur cette piste, je me repencherai plus tard sur la raison. Je n'en dis pas plus pour ne pas dire d'approximation mais je suis je pense comme davidM que la notion de hiérarchie ne fait pas vraiment partie de drupal (il a fallut attendre le module book sur drupal 6 pour que je trouve enfin quelque chose qui y ressemble vraiment de base)
Ce qui me pose probleme entre autres c'est qu'un vue devrait pouvoir appartenir à une rubrique (avoir pour parent un node). Il en va de même pour d'autres pages mais ça me manque vraiment de ne pas pouvoir incorporer les views dans cette logique de rubrique de façon simple. C'est pour ça que le module context semble une bonne piste mais ça finit en usine à gaz pour reproduire un comportement à la Modx.
En fait drupal propose tout un tas de solution à gauche à droite pour gérer cette histoire de hiérarchie à travers différents modules mais j'aimerai trouver un truc pour centraliser ce concept de façon plus limpide; qu'il y a ait clairement un concept de RUBRIQUE qui apparaissent en tant que tel dans drupal (et dans les vues) indépendamment de la taxonomie ou du module book qui n'a pas spécifiquement cet usage.
Je pense comme toi que la logique du core de drupal est trop éloigné de celle de Modx pour obtenir un résultat similaire mais je suis persuadé qu'avec un peu d'astuce et un bon module il y aurait moyen de "modixer" drupal sur plusieurs points.
Je pense notamment à la gestion de l'affichage des variables d'un node qui pourrait être controlé de manière plus sympa que contemplate...
(Je serai ravi de discuter de cela avec toi à l'occasion, peut être demain soir si tu es toujours dispo ;-) )
Salut, CCK + Node
Salut,
CCK + Node relationship me semble répondre à ce besoin :
Pour un type de node donné tu spécifie qu'il a un lien avec tel autre node de tel autre type de node.
(ex: telle page est liée avec telle vidéo).
A toi de savoir si ce sont des liens parents/enfants ou enfant/parents ou égal à égal.
Ensuite c'est une question de template à mon avis...
"L'exces de modération nuit gravement à la consommation"
Materiel et services agrométéorologiques : http://www.promete.fr
http://cocoate.com/2009/08/16
http://cocoate.com/2009/08/16/node-references-module-node-relationships
Un billet récent (en anglais) sur Node Relationships.
I stand corrected comme on dit en anglais
Ok j'ai été un peu trop vite (ça m'arrive, parfois le proc surchauffe :P)
Je vais explorer cet aspect de Book dans ce cas....
@Nyl : oui toujours dispo pour une Chouffe :D
Pour ce qui est de modxifier Drupal je pense que D7 va dans ce sens et que D7 se rapproche de modx revolution, avec probablement moins de degré de liberté pour employer un terme un peu ésotérique emprunté à la chimie...
Pour faire du spip avec
Pour faire du spip avec drupal, le plus simple est d'utiliser la taxonomie avec le module taxonomy_treemenu et … des css
Ça fait deux mois que j'utilise la V6 et je suis en passe de laisser tomber la longue liste de tout ce que j'ai utilisé avant. Avec l'installation multisite qui est incontournable.
http://twitter.com/cyberjimi
Node hierarchy
Bonjour,
Connais-tu ce module ? http://drupal.org/project/nodehierarchy
Je pense qu'il ressemble à ce que tu veux...
retour d'expérience
bon, me revoici quelques mois plus tard. Le meilleur moyen d'organiser une hiérachie dans Drupal 6 reste la taxonomie; surtout étant l'avancée majeur de views 2 qui permet de lister la taxonomie (et donc d'afficher physiquement des rubriques facilement, ce qui n'était pas possible si facilement dans la 5). Allié à taxonomy image, ça correspond déjà plus à un systeme de rubriques.
De toute façon, à la différence de Modx où TOUT élément est dans un conteneur (appellé document) hiérarchisable; dans drupal les modules fournissent tous leur page tout patatrac sans aucune notion de hiérarchie ou de rubrique. Donc ça restera toujours un point faible de Drupal car je ne vois comment intégrer ça via le systeme de menu actuel.
C'est pour cette raison qu'il faut parfois de farcir des modules comme context, node breadcrumb, taxonomie breadcrumb, tous là pour maintenir l'illusion d'un rubriquage ou d'une hiérarchie qui en réalité n'existe pas et n'existera pas de sitôt.
A priori la meilleure combinaison actuellement me parait taxonomie + taxononomy breadcrumb + context. (plus un module pour le menu hiérarchisé)
Pour ce qui est de la "liaison de contenu" en parent-enfant, à mon sens ni le module book ni node hierachy ne fournissent une réponse satisfaisante. Pour des raisons ergonomiques, le module book ne convient pas (en plus il faut choisir un type de contenu par défaut pour le lien "ajouter un efant), il est conçu pour du wiki hiérarchisé ce qui n'est pas le même besoin. Le module node hierarchy peche parce que type de contenu peut être enfant ou parent mais on ne peut pas dire de QUEL type de contenu ils peuvent être parent ou enfants; je trouve ça très dommage :-(
Sinon du côté des problématiques parent-enfants (je change un peu de débat mais bon c'est lié) du genre
"je veux pouvoir créer un type de contenu "artiste musical". Sur ce node artiste, je veux un lien ou onglet pour créer un type de contenu "album" qui a pour parent automatiquement le node artiste. Et sur ce type de contenu, je veux pouvoir créer un type de contenu enfant "chanson" qui a automatiquement pour node parent l'album. (avec en prime un lien de la chanson vers son album, et de l'album vers son artiste).
Vous je ne sais pas, mais moi à chaque site ou presque je rencontre ce besoin, que sur drupal 5 je comblais avec un node reference caché et un petit module qui le remplissait avec le bon parent en fonction du type de contenu. Existe-t-il un module permettant de faire ça sur Drupal 6.
Ni book ni node hierarchy ne permettent de faire ça pour des raisons ergonomiques car en gros ils ne permettent pas de dire que tel type de contenu doit afficher forcément un lien pour créer tel autre type de contenu (par ex : les types de contenus album affiche un onglet pour ajouter un type de contenu "chanson", point à la ligne, fin de l'histoire).
Si je ne trouve pas dans les prochaines semaines un module qui fait ça, je m'y attelerai mais ça m'étonne que ça n'existe pas encore? (mais après moults test, node hierarchy et book sont pas utilisables de cette façon sauf à les modifier un peu.)
Roadmap Node Hierarchy
As-tu vu la roadmap de node Hierarchy ?
To Do
* Improve "Can be child" setting to allow admins to specify which node types can be children of which node types. (e.g. 'chapter' nodes can only be children of 'book' nodes)
* Drag and drop reordering and parent changing.
* OPML import and export
Et le changelog de la version 2 ?
The 2.x branch of node hierarchy is a ground up rewrite which uses the core drupal 6 menu system to store the parent-child relationships. This allows for significantly improved performance and scalability and significantly simpler code. Other new features include:
Usability improvements including drag and drop reordering of children.
Simplified node edit screen.
Ability to restrict parent-child relationships by type.
Ability to have multiple parents (interface not implemented yet)
Je n'ai pas testé (en particulier je ne sais pas si c'est encore utilisable en V2) mais peut-être que cela vaut le coup de regarder pour savoir si tu peux aider...
hello
ah non, pas regardé la roadmap :-) (un nouveau réflexe à prendre)
C'est effectivement exactement ce que je recherche et ça permettrait d'enfin gérer très facilement des relations parents-enfants dans drupal. Pour peu que le module donne la possibilité de themer où et comment on ajoute une page; alors on aura vraiment une solution élégante pour pouvoir batir pas mal d'applications via drupal.
(type de contenu + cck + relations parents-enfants + views + rules ou module maison = un tas d'applications facile à imaginer et rapide à développer :-) )
En effet je vais voir si je peux contribuer sur ce module plutôt que de partir seul de mon côté...
Merci de ton avis !
Merci pour la roadmap
Intéressant cette info si le module correspond à ce qui est annoncé, ça pourrait être enfin une solution digne de ce nom pour gérer la hiérarchie ("typée") des contenus :)
Je pense que je n'ai pas
Je pense que je n'ai pas encore le niveau pour contribuer sur un module de ce genre, je suis encore un apprenti jedi de drupal 6.
Pour ce qui est de la relation parents-enfants du type "un membre peut créer un node album qui peut créer des nodes chansons" j'ai décidé de développer un module spécifiquement pour ce besoin car ça me manque trop et je ne vois pas d'équivalent (book : orienté wiki; nodehierarchy : pas possible de choisir quel type de contenu ajouté à quel type de contenu).
Si vous connaissez un module qui fait spécifiquement ce que je décris en bas, merci de me le dire, je lacherai mon développement en cours :
L'idée du module c'est de pouvoir par exemple pouvoir créer sans souci (par exemple) une gestion de projet avec drupal (ou autre application),:
- on crée un type de contenu "projet"
- on crée un type de contenu tache, un type de groupe de tache, un type de contenu évènement
- on va dans l'administration du module et on coche pour le type de contenu "projet" les types de contenus tache, groupe de tache, event.
- En retournant sur une fiche projet, on voit désormais des onglets (tabs local task) "add new event" et idem pour les autres types de contenus enfant.
- en cliquant sur ces onglets , on affiche un formulaire de création et à l'enregistrement (aucune variable ne circule par l'url, j'aime pas trop l'idée de laisser le parent dans l'url, modifiable par l'utilisateur...), les types de contenus enfants sont automatiquement rattachés à leur projet parent (à la manière de node hierarchy, sauf qu'il n'y pas pas l'étape de passer par l'onglet children)
- les nodes enfants affichent automatiquement un lien de retour vers le parent; lien que l'on peut entièrement themer via un template : ce template contient tous les variables de l'objet node parent. On peut donc afficher la fiche complète du projet dans un node de type groupe de tache par exemple.
- n'importe quel node peut afficher un lien de retour au "parent ultime" (la fiche projet ici), également themable, le template contenant la totalité de l'objet node projet dans cet exemple.
-intégrations avec views : c'est ce point que je ne maitrise pas, faut que je trouve un bon tuto..
Petite pierre à l'édifice...
Bonjour à tous,
Voic ma petite pierre à l'édifice. Voici un tuto video qui te montre comment rajouter une photo dans une galerie. http://www.lullabot.com/articles/photo-galleries-views-attach. avec views attach module. Je pense que le concept de créer un objet dans un autre objet est là même s'il faut bien sûr modifier ça pour le mettre dans ton contexte (créer une fiche projet dans un groupe de projet).
Après pour ce qui concerne la notion de parent-enfant, je pense qu contraire que la force de Drupal consiste à ne pas t'enfermer dans une logique obligatoire parent-enfant mais de proposer un système qui te donne le libre choix de construire ta structure logique (horizontal, vertical ou par arborescence). Pour moi, il suffit juste de jouer sur la taxinomie, le champ node relationship, taxinomy_menu (ou de construire toi-même ta liste avec views ou dans un module) et de personnaliser le breadcrumb. Dans ton cas, tu as deux solutions.
Soit de créer des types de contenus pour projet, groupe de projet, fiche projet, fiche event, de créer un champ node relationship entre chaque type de contenus (ex : entre projet et groupe de projet; groupe de projet et fiche projet) et de créer tes blocs ou pages qui permettaient d'afficher les liens vers tous ces contenus suivant la vue que tu souhaites (avec views ou via un module). L'avantage est de pouvoir bénéficier de CCK pour rajouter des infos dans les différents types de contenus (type champ description dans le contenu projet, liens avec des fiches utilisateurs...).
Soit de créer une taxinomie qui listerait et ordonnancerait les projets et les groupes de projets suivant une arbo parent / enfant (facile avec le drag and drop dans D6) et qui serait appliquée sur les types de contenus fiche projet et fiche event. Après à toi de créer tes pages et blocs pour afficher ça.
Bon après peut-être que tout ce que je dis est à côté de la plaque pour tes besoins (ou alors que tu y as évidemment déjà pensé et là je viens de passer 15 mn à rédiger tout ça pour rien :)).
Julien Didelet
Julien Didelet
Founder
Weblaa.com
Hello :-)
"le champ node relationship"
La je ne sais pas de quoi tu parles : des relationships des views ? d'un module relationship? Je ne comprends pas la méthode, peux tu développer ?
Ah oui pardon mdr
Désolé j'ai tapé trop vite. Je voulais dire des nodes reference dans cck.
Julien Didelet
Julien Didelet
Founder
Weblaa.com
Ah ok :-) En fait c'est bien
Ah ok :-)
En fait c'est bien la méthode que j'utilise depuis drupal 5 pour la liaison de contenu CCK node reference + views.
Le petit module dont je parle se contente de simplifier au maximum ce fonctionnement tout en gardant sa flexibilité. (le probleme avec un champ CCK reference c'est que je dois parfois le MASQUER à l'utilisateur car l'opération doit pouvoir être transparente pour lui. Et là c'est pas pratique, faut mettre un hook form alter, préselectionner le bon élément dans la liste déroulante etc... sachant que le nom du champ change alors pas possible de copier coller tout ça à chaque fois)
Et avec views-attach ?
Et avec views_attache et la méthode lullabot, ça ne marche pas ?
Julien Didelet
Julien Didelet
Founder
Weblaa.com
Dès que j'ai le temps de
Dès que j'ai le temps de regarder la vidéo en entier je te donne un retour :-)
Très malin le node reference url comme module!
Par contre j'avoue avoir un petit souci avec le fait de faire passer cette donnée capitale (nid du node lié) dans l'url - donc modifiable par un internaute, j'attends de voir la vidéo.
Merci pour ces pistes !
Ok je viens de voir la
Ok je viens de voir la vidéo. Je comprends pas très bien l'anglais et je n'ai pas compris comme il rajoutait le fameux lien "ajouter une photo" qui contient le nid du node dans l'url (pied de page de la vue? ) edit : ok j'ai compris, c'est carrément node reference url qui peut rajouter ce lien apparemment. C'est très ingénieux ce module.
Node reference url est vraiment très très intéressant, j'aime beaucoup l'idée; c'est lui la pierre angulaire de tout le systeme en fait.
Par contre je suis peut être parano mais quid si l'utilisateur change le nid dans l'url ? En changeant l'url j'alloue ma photo à un album qui n'est pas moi, je ne devrais pas avoir cette possibilité. C'est pour ça que je suis plutôt parti sur des local tasks maintenant...
En tous cas une solution incontournable à sérieusement envisager pour qui veut créer des relations entre node en toute flexibilité. Merci pour le lien :-)
Question de droit d'accès après
Oui je pense aussi que c'est un bon module. Assez user-friendly en tout cas. Sinon pour la question url, je pense que tout est une question de droit que tu attribues vu que tu peux choisir entre "edit your own gallery" ou "edit any gallery". Si tu attribues le premier droit, la personne ne pourra pas ajouter de photos même s'il change l'url (heureusement d'ailleurs). Mais si tu lui attribues le deuxième droit, il pourra de toute façon ajouter une photo car il en aura les droits.
Julien Didelet
Julien Didelet
Founder
Weblaa.com
Eddyl et Julien mentionnent
Eddyl et Julien mentionnent le module Node Relationships http://drupal.org/project/noderelationships
Cela me semble une excellente piste.
J'ai pas testé mais si vous avez le temps.
Alex
www.ineation.com
Alex
www.ineation.com
effectivement, j'étais
effectivement, j'étais passé trop vite dessus à l'époque. Je vais le tester dans un cas pratique tout de suite.
Tiens nous au courant
Tiens nous au courant !
Alex
www.ineation.com
Alex
www.ineation.com
bon, comme chaque fois qu'il
bon, comme chaque fois qu'il y a du javascript en jeu, j'arrive à pas à faire une installation propre au premier coup. je teste tout ça ce week end et je fais une synthese de toutes me expériences avec node hierachy, node reference url et noderelationships.
retour d'expérience
Je viens d'essayer noderelationships [ http://drupal.org/project/noderelationships ] donc je fais un petit compte rendu pour ceux que cela intéresse. je pense que je vais faire un tuto sur drupalfr pour synthétiser tout ça.
Node reference Url s'adresse à ceux qui veulent pouvoir créer un enfant à partir d'un parent à partir d'un lien, de façon complètement transparent pour l'utilisateur. par exemple c'est vraiment l'idéal pour ajouter un "type de contenu" tache à un type de contenu "groupe de tache". Ca permet de lier par node reference sans avoir à sélectionner le contenu dans la liste déroulante.
Noderelationships est plutôt prévu pour choisir sans difficulté parmi un large choix un node à lier : Il n'a pas de sens dans une utilisation du style "une tache doit appartenir à un groupe de tache". En revanche son excellente ergonomie le rend très perfomant pour faire des choses du types "à qui assigner cette tache?" là on a une joli fenêtre modale qui s'ouvre, la possibilité de sélectionner en ajax la personne à qui assigner la tache, et même un petit moteur de recherche ajax au cas où le choix de node se fait trop nombreux . Il permet meme de créer à la volée un nouveau parent et de le référencer.
(et pour terminer ya un joli diagramme des relations).
Les deux ne peuvent pas utiliser le même champ (noderelationships demande un champ autocomplete tandis que node reference url définit son propre widget); en revanche en combinant les deux selon les cas de figure on peut tisser de façon très ergonomique des relations : node reference url plutôt pour une création transparente et personnalisée de parent enfant, et relations ships pour des relations plus transversales.
La dernière pierre de l'édifice c'est views 2 puisqu'il permet très facilement d'afficher les enfants d'un node parent; mais aussi très facilement de créer un affichage personnalisé du parent sur l'enfant en jouant sur les "relationships" que node reference rend très simple !. (imaginons que l'on veuille afficher sur une fiche album une mini-fiche de son artiste parent; c'est une très bonne solution, hors php).
Il me reste node2node à explorer mais c'est node reference URL combiné avec relationships de views 2 qui se rapproche le plus d'un systeme de relation intuitif et souple je trouve. Et au final c'est ce qui reprend de façon plus simple la logique du php : créer une relation entre deux nodes avec la BDD relationnelle (node reference), puis sql et jointures de table pour récupérer ses petits (views 2). A partir de ces deux principes, on fait un peu ce qu'on veut en configurant bien tout le bazar :-)
My two cents.
CCK + Nodereference + Noderelationships + THEMING
Bonjour à tous,
En réponse à tous ces posts et à une conversation que j'avais déjà eu avec Julien Didelet sur la gestion des médias. Je vous joins des screenshots de travail...
J'avais un besoin pour un site de gérer les contenus suivants :
image : avec titre, le fichier image et une légende stockée dans le body => utilisation de imagecache pour gérer les formats vignettes, etc...
galerie : un groupe de N images avec titre de la galerie et texte d'accompagnement (body aussi) => utilisation de
vidéos : idem fichier + titre + body
sons : fichier + titre + body
pages (c'est là que cela devient intéressant) : avec titre, body (mise en forme avec FCKEditor + Intégration d'Image assist pour les vignettes et lightbox sur les images) et 4 champs CCK node reference (pages liées, vidéos liées, sons liés, galeries liées à cette page).
J'ai donc satisfait ces exigences avec l'utilisation de CCK node reference + Noderelationship + Node Explorer (la fenêtre modale qui permet de sélectionner les nid à insérer dans le champ CCK).
Le module d'admin de noderelationships permet simplement et facilement de créer les relations.
Création du content type, classique
Affichage des relations, purement informatif
Extras, ici bien penser à cocher les cases !
Ici ce que ça donne lors de l'édition du node. On a accès aux boutons insertion et création à la volée d'un node.
Recherche et Sélection d'un node
J'ai modifié la vue par défaut pour Prévisualiser le node (target=_new) avant son insertion. NDLR L'idéal serait de le faire avec lightbox, mais j'arrive pas à 'sortir' de la modale.
Ici la Création et Sélection d'un node dans NodeExplorer.
Et voici ce qui est stocké dans le widget.
Ensuite, pour arriver à un joli résultat, tout est dans le 'theming' des nodes. Dans notre cas le node-page.tpl.php est complètement personnalisé afin de récupérer dans le tableau les nids des pages, vidéos, sons, galeries liées. Ainsi pour notre charte, on insère, s'il y a au moins un de ces contenus un lien (image/texte) cliquable avec lightbox, qui ouvre des vues personnalisées (listes des pages, vidéos,... liées) avec lien cliquable pour aller voir ces liens.
Pour info : j'ai entrepris la traduction de noderelationships et d'image assist mais va encore falloir du temps, je suis surbooké.
Je veux bien collaborer à un tuto sur et autour noderelationship et un sur fck + image assist + imagecache
Piste à approfondir :
- Le passage de paramètres à la fenêtre modale de nodeexplorer (c'est une vue) doit permettre de restreindre encore la liste de nodes 'insérables'; pour des relations plus poussées (les pages du même auteur,...?) et comme c'est une fenêtre modale Y PAS DE PARAMÈTRE DANS L'URL
- Arriver à prévisualiser le node depuis la modale de nodeexplorer dans une lightbox, plutôt que avec un attribut target=_new
Edouard
"L'exces de modération nuit gravement à la consommation"
Materiel et services agrométéorologiques : http://www.promete.fr