"context" on the drupal page

Question

This question is general, and I have already posted a version here . I hope, however, that I will have a better chance of getting an answer and be useful to more people by asking in this forum.

Linking content together when it loads on the drupal page is tricky. In drupal, each page, regardless of the site, is basically the same: you have the main content in the middle (view, node or several nodes), with blocks surrounding this central content. In order for the blocks to somehow know what is in the middle (especially since they know about each other), you either need to do some really bizarre work in your own module, or you need to make the "arguments" available in Url.

I studied the spaces / context / features / purl set of modules provided by developmentseed, and I also reviewed Panels / Ctools made by Earl Miles (the guy who wrote the opinions). While both provide tools to make my work easier, my understanding of each of them is that I still need to put “arguments” in the URL if I want the contents of my blocks to be determined by my “context” (I I use this in a general sense, and not in a specific sense, denoted either by the context module or the concept of context in Ctools).

Am I missing something, or is this where we are with Drupal?

Finally, I must say in conclusion that I know of other modules that help with such things on a limited basis in each case. Views attach module and Node reference views , for example, each of them takes a hit on solving this problem for a very specific use case. They are both good modules, and there are others like them, but I really would like to find a solution to this problem as a whole.

Answer 1

I think I do not quite understand what you are aiming for, but I will try, nonetheless:

For each non-static website, whether it is based on Drupal or something else, there are two main things that provide a “context” for deciding what content should be delivered for a given request.

The first and most important is obviously the request itself . This is the only information that is always guaranteed. In most cases, it will just be a GET request, and with that, the URL is implicitly the main source of "context". POST requests may provide a little more “context” besides the URL, but for your question, you could argue that they are just a more sophisticated version of the GET request, providing a few more “arguments” other than those specified in the URL (and in most cases, one could request a POST in a GET request with a more complex URL).

The second function of the contextual provision of the session . No matter what kind of processing a session of the mechanism is based on (basically, cookies at present), the goal is always the same: to transfer some “state” information across the border of stateless requests by default. This is done by linking a given request to information from previous requests stored on the server side. This allows you to "enrich" the information available to decide what content should be delivered for the request. In principle, one could consider this as a way to add a few more “arguments” to the request.

What is it. Any other information needed to build the response must somehow be obtained from the information specified in the request (and we can say that session processing is already the main process for this, adding a “context” based on a cookie or some other identifier with a request).

Drupal reflects this process very well, IMHO, because it first collects the "main" content for the response based on the URL with additional information (for example, about the user) that is "attached" to the session. Only after the main content has been collected through a call to $return = menu_execute_active_handler() in index.php, add other response elements (for example, blocks, menus, etc.), Calling theme('page', $return); .

Thus, regardless of what you want to “transfer” to these other elements, you need to either “re-extract” it from the information already used to assemble the main content (URL, session), or you need to temporarily store it during the generation of the main context. You can do this in many ways, for example. adding it to information already stored in the session, using static caching in some functions, setting global variables (not); transferring material through a database, etc.

So, I don’t seem to understand what you are aiming for. What are you missing here?

Answer 2

A good answer from Henrik, but I would like to add that there can be quite a lot of information in the request, except for the state of the cookie. Think about important HTTP headers like reception or language or even X-REQUEST. Most webframework wraps this information in one convenient data structure. Unfortunately, from the above answers I have to conclude that drupal does not.