4

这个问题是一个普遍的问题，我已经在这里发布了它的一个版本。不过，我希望通过在这个论坛上提问，我将有更好的机会得到回应，并对更多的人有用。

当所有内容都加载到 drupal 页面上时，将内容关联在一起是一件棘手的事情。在 drupal 中，每个页面，无论是哪个站点，都基本相同：中间有主要内容（一个视图、一个节点或多个节点），围绕该中心内容的块。为了使块以某种方式了解中间的内容（更不用说彼此了解），您要么必须在自己的自定义模块中做一些非常花哨的步法，要么必须在 URL 中提供“参数”。

我一直在研究 developmentseed 提供的空间/上下文/功能/ purl模块套件，并且我还研究了Earl Miles（编写视图的人）制作的Panels / Ctools模块。虽然两者都提供了使我的工作更轻松的工具，但我对每一个的理解是，如果我想要由我的“上下文”定义的块的内容，我仍然需要在 URL 中放置“参数”（我通常使用它）意义，而不是上下文模块或 Ctools 中的上下文概念所指的特定意义）。

我错过了什么，还是我们在 Drupal 的地方？

最后，我应该在结束时说，我知道其他模块可以在有限的情况下帮助解决此类问题。例如，视图附加模块和节点参考视图模块都针对一个非常具体的用例尝试解决这个问题。它们都是很好的模块，还有其他类似的模块，但我真的很想找到解决这个问题的方法。

4

2 回答 2

7

我想我不太明白你的目标是什么，但我还是会尝试：

对于每个非静态网站，无论是基于 Drupal 还是其他任何东西，都有两个基本的东西为决定为给定请求提供什么内容提供“上下文”。

首先也是最重要的显然是请求本身。这是唯一保证始终存在的信息。在大多数情况下，这将只是一个 GET 请求，并且对于这些请求，URL 隐含地是可用的“上下文”的主要来源。除了 URL 之外，POST 请求可以提供更多“上下文”，但对于您的问题，有人可能会争辩说它们只是 GET 请求的一种更复杂的变体，除了来自 URL 的那些（以及在大多数情况下，无论如何都可以将 POST 请求转换为具有更详细 URL 的 GET 请求）。

第二个“提供上下文”的东西是session。无论会话处理基于什么机制（现在主要是 cookie），目标总是相同的，即携带一些“状态”信息跨越固有无状态请求的边界。它通过将给定请求与来自先前请求的信息相关联来实现这一点，这些信息存储在服务器端。这允许“丰富”可用于决定为请求提供什么内容的信息。基本上，可以将其视为向请求添加更多“参数”的一种方式。

就是这样。组装响应所需的任何其他信息都需要以某种方式从请求中给出的信息中导出（并且可以说会话处理已经是这样做的主要过程，通过添加基于 cookie 或其他一些标识符的“上下文”随请求而来）。

Drupal 很好地反映了这个过程，恕我直言，因为它首先根据 URL 为响应组装“主要”内容，并在会话中“附加”附加信息（例如关于用户的信息）。只有在通过调用$return = menu_execute_active_handler()index.php 组装了主要内容之后，才会通过调用添加响应的其他元素（例如块、菜单等）theme('page', $return);。

因此，无论您想要“传递”给其他元素的“上下文”是什么，您要么必须从已经用于组装主要内容（URL、会话）的信息中“重新提取”它，要么必须暂时存储它在主要上下文的生成过程中。您可以通过多种方式执行此操作，例如将其添加到已存储在会话中的信息中，在某些函数中使用静态缓存，设置全局变量（不要；），通过数据库传递内容等。 .

再说一次，我似乎不明白你的目标是什么。你在这里缺少什么？

于 2009-12-18T14:51:14.067 回答
5

Good answer from Henrik but I'd like to add that there can be quite a lot of information in the request beside maintaining state with cookies. Think important HTTP headers like accept or language or even X-REQUESTED-WITH. Most webframeworks wrap this information into one convenient datastructure. Unfortunately from the answers given I have to conclude that drupal doesn't.

于 2010-06-20T16:43:53.560 回答