这个问题很简单，我已经发布了here的版本。不过，我希望通过在这个论坛上提问，我有更好的机会得到回应，对更多人有用。
将内容加载到drupal页面上时将内容关联在一起是一项棘手的工作。在drupal中，每个页面（无论站点）基本相同：您在中间（视图，节点或多个节点）具有主要内容，其中包含围绕该中心内容的块。为了让这些块在某种程度上意识到中间是什么，（更不了解彼此）你要么在你自己的自定义模块中做一些非常花哨的步法，要么你必须在URL中提供“参数”。
我一直在研究developseed提供的spaces / context / features / purl模块套件，我也研究了{{3 Earl Miles（撰写观点的人）制作的/ Panels模块。虽然两者都提供了使我的工作更轻松的工具，但我对每个工具的理解是，如果我想要通过我的“上下文”定义的块的内容，我仍然需要在URL中放置“参数”（我在一般情况下使用它感觉，而不是在上下文模块或Ctools中的上下文概念所指的特定意义上。）
我错过了什么，或者是我们和Drupal在一起的地方？
最后，我应该在结束时说，我知道其他模块可以在有限的个案基础上帮助解决这类问题。例如，Ctools模块和Views attach模块都针对一个非常具体的用例尝试解决此问题。它们都是很好的模块，还有其他类似的模块，但我真的很想找到解决这个问题的方法。
答案 0 :(得分：7)
我想我真的不明白你的目标是什么，但我会尽力去尝试：
对于每个非静态网站，无论是基于Drupal还是其他任何内容，有两个基本内容可以为决定在给定请求时提供什么内容提供“上下文”。
第一个也是最重要的事情显然是请求本身。这是唯一始终保证在那里的信息。在大多数情况下，这只是一个GET请求，对于这些请求，URL隐含地 可用的“上下文”主要来源。除了URL之外，POST请求可以提供更多的“上下文”，但对于您的问题，可以说它们只是GET请求的一个更复杂的变体，除了URL中的那些之外提供了更多的“参数”（并且在大多数情况下，无论如何都可以将POST请求转换为具有更精细URL的GET请求。
第二个“提供背景”的事情是会话。无论会话处理基于什么机制（现在主要是cookie），目标总是相同的，即在本质上无状态请求的边界上携带一些“状态”信息。它通过将给定请求绑定到存储在服务器端的先前请求的信息来完成此操作。这允许“丰富”可用于决定为请求提供什么内容的信息。基本上，人们可以将其视为向请求添加更多“参数”的方式。
就是这样。组合响应所需的任何其他信息需要以某种方式从请求中给出的信息中获得（并且可以说会话处理已经是这样做的主要过程，通过基于cookie或其他标识符添加'context'提出要求）。
Drupal很好地反映了这个过程，恕我直言，因为它首先汇总基于URL的响应的“主要”内容，并在会话中附加了“附加”的附加信息（例如关于用户）。只有在主要内容通过在index.php中调用$return = menu_execute_active_handler()组装后，才能通过调用{添加响应的其他元素（例如块，菜单等） {1}}。
所以无论'上下文'是什么，你想要“传递”到那些其他元素，你要么必须从已经用于组装主要内容（URL，会话）的信息中“重新提取”它，要么你必须在生成主要上下文期间临时存储它。您可以通过多种方式执行此操作，例如：通过在一些函数中使用静态缓存，通过设置全局变量（不要;），通过数据库传递东西等，将它添加到已经存储在会话中的信息中......
所以，我似乎并不明白你的目标是什么。你在这里缺少什么？
答案 1 :(得分：5)
Henrik的答案很好，但我想补充说，除了使用cookie维护状态之外，请求中可能会有很多信息。认为重要的HTTP标头，如接受或语言，甚至X-REQUESTED-WITH。大多数webframeworks将此信息包装到一个方便的数据结构中。不幸的是，根据给出的答案，我必须得出结论，drupal没有。