"context" sur une page drupal

Question

Cette question est générale, et j'en ai déjà posté une version here. J'espère cependant que j'aurai plus de chances d'obtenir une réponse et d'être utile à plus de gens en posant des questions dans ce forum.

Associer du contenu ensemble lorsque tout se charge sur une page drupal est une entreprise délicate. En drupal, chaque page, quel que soit le site, est fondamentalement la même: vous avez un contenu principal au milieu (une vue, un nœud ou plusieurs nœuds), avec des blocs autour de ce contenu central. Pour que les blocs soient en quelque sorte au courant de ce qui se trouve au milieu (beaucoup moins conscients l'un de l'autre), vous devez soit faire un jeu de jambes dans votre propre module personnalisé, soit fournir des arguments dans l'URL.

J'étudie la spaces/context/features/purl suite de modules fournis par developmentseed, et je l'ai aussi regardé dans les modules Panels/Ctools faites par Earl Miles (le gars qui a écrit des vues). Bien que les deux fournissent des outils pour faciliter mon travail, ma compréhension de chacun est que je suis toujours tenu de placer des "arguments" dans l'URL si je veux que le contenu de mes blocs soit défini par mon "contexte" (je l'utilise dans le sens, et non dans le sens spécifique voulu par le module de contexte, ou le concept de contexte dans Ctools). Est-ce qu'il me manque quelque chose, ou est-ce là où nous en sommes avec Drupal? Enfin, je dois dire en terminant que je suis au courant d'autres modules qui aident à ce genre de choses sur une base limitée, au cas par cas. Le module Views attach et le module Node reference views, par exemple, tentent chacun de résoudre ce problème pour un cas d'utilisation très spécifique. Ce sont deux bons modules, et il y en a d'autres comme eux, mais j'aimerais vraiment trouver une solution à ce problème en général.

Answer 1

Je suppose que je ne comprends pas vraiment ce que vous visez à, mais je vais essayer quand même:

Pour chaque site non statique, que ce soit basé sur Drupal ou quoi que ce soit d'autre, il y a deux choses fondamentales fournissant le «contexte» de la décision sur le contenu à livrer pour une demande.

La première chose et la plus importante est évidemment la demande elle-même. C'est la seule information qui est toujours garantie d'être là. Dans la plupart des cas, il s'agira simplement d'une requête GET, et avec celles-ci, l'URL est implicitement la source principale disponible. Les requêtes POST peuvent fournir un peu plus de 'contexte' en plus de l'URL, mais pour votre question, on pourrait argumenter qu'il s'agit simplement d'une variation plus compliquée d'une requête GET, fournissant plus d'arguments en plus de ceux de l'URL (et dans la plupart des cas, on pourrait transformer une requête POST en une requête GET avec une URL plus élaborée de toute façon).

La deuxième chose 'fournissant le contexte' est la session. Quel que soit le mécanisme de gestion de la session (principalement les cookies de nos jours), le but est toujours le même, à savoir de transmettre des informations «d'état» à travers la limite de requêtes intrinsèquement sans état. Il le fait en liant une requête donnée aux informations des requêtes précédentes, stockées côté serveur. Cela permet d '«enrichir» l'information disponible pour décider du contenu à livrer pour une demande. Fondamentalement, on pourrait considérer cela comme un moyen d'ajouter d'autres «arguments» à la demande.

Et c'est tout.Toute autre information nécessaire pour assembler une réponse doit en quelque sorte être déduite des informations fournies dans la requête (et on pourrait dire que la gestion de session est déjà le processus principal en ajoutant un 'context' basé sur un cookie ou un autre identifiant venir avec la demande). Drupal reflète assez bien ce processus, à mon humble avis, car il assemble d'abord le contenu «principal» pour une réponse basée sur l'URL, avec des informations supplémentaires (par exemple sur l'utilisateur) «attachées» dans la session. C'est seulement après que le contenu principal a été assemblé en appelant $return = menu_execute_active_handler() dans index.php, que les autres éléments d'une réponse sont ajoutés (par exemple des blocs, des menus, etc.), en appelant theme('page', $return);. Donc, quel que soit le 'contexte' que vous voulez 'passer' à ces autres éléments, vous devez soit le 'ré-extraire' des informations déjà utilisées pour assembler le contenu principal (URL, session), ou vous avez pour le stocker temporairement pendant la génération du contexte principal. Vous pouvez le faire de plusieurs façons, par ex. en l'ajoutant aux informations déjà stockées dans la session, en utilisant la mise en cache statique dans certaines fonctions, en définissant des variables globales (ne pas;), en passant des données dans la base de données, etc ...

ne semble pas comprendre ce que vous visez. Qu'est-ce qui vous manque ici?

Answer 2

Bonne réponse de Henrik mais je voudrais ajouter qu'il peut y avoir beaucoup d'informations dans la demande à côté du maintien de l'état avec des cookies. Pensez aux en-têtes HTTP importants comme accepter ou utiliser la langue ou même X-REQUESTED-WITH. La plupart des webframeworks enveloppent ces informations dans une infrastructure de données pratique. Malheureusement, à partir des réponses données, je dois conclure que Drupal ne le fait pas.