Phase 1: Context

This is mostly a repost with some tweaking based on the previous discussion thread. The biggest difference is the adoption of a global "context stack" to handle legacy components. I've also merged Phase 1 and Phase 2, since both are part of the context system itself.

Step 1:

During bootstrap, we create a context object instance of a class with a defined interface. This object will initially contain information derived from the HTTP request itself. The context object will be responsible for ensuring sane defaults are returned in unusual cases.

• GET parameters
• POST parameters if any
• Cookie values
• Session information
• $_SERVER information
• Additional information available directly from the HTTP request or equivalent

It will also include the following derived information that other code may assume is always present. The context object will be responsible for ensuring sane defaults are returned in unusual cases.

• Current language
• Requested path (both raw and de-aliased)

The context object will also offer centralized access to the following derived contextual information that MAY be lazy-loaded on request.

• Current user (Because this is explicitly driven by session/cookie in the Request)
• Level-1 loaded entities (i.e., what is currently loaded by %node and similar menu callbacks)
• Pager state
• Others that may be found during implementation

The context object will not be alterable. Once a given element of context has been determined, it will remain constant for the remainder of that context object's lifetime.

The context object will, however, provide a mechanism to wrap itself in a mock context object that allows for overriding of selected context elements at creation time only. This mechanism is modeled on the mocking mechanism present in many testing frameworks. The wrapped context object may then be passed on to other routines which will then not know that those elements have been mocked.

Every time a context object is mocked, the newly mocked object will be pushed into a central context stack. When a mocked context object is no longer needed (either explicitly or it goes out of scope or some other trigger causes it to be necessary) it will be popped off of the global stack.

Dries has suggested investigating similar Java-based systems that implement a concept of context for dependency injection and will provide resources for further investigation.

Step 2:

A global accessor mechanism, most likely a drupal_get_context() function, will be provided. This accessor will do nothing except return the current context object so that modules and core APIs may act upon the context as appropriate. The "current context object" is defined as the top-most object in the central context stack described above.

Object-oriented systems that require the central Drupal context will be designed to accept a context object as a constructor parameter. It will be considered a bug for such a system to call the drupal_get_context() function directly.

Procedural systems may if appropriate be adapted to accept a context object as a parameter. Alternatively, they may be adapted to call drupal_get_context() in their first line to gain access to the current context. That distinction will be made on a case-by-case basis.

Step 3:

All existing uses of one-off context in core will be removed in favor of the central context object. These include, but are not limited to, arg(), drupal_get_normal_path(), the global $user and $language variables, the $pager_* globals, all references to PHP super globals ($_GET, $_POST, etc.), and numerous other instances of scattered context. This functionality will be available in a more robust and abstracted form in the context object. Once all uses of such scattered context are expunged, the existing mechanisms will be removed. (That is, arg() will be removed from core in this step. There will then be a party that includes ponies.)

Step 4:

A backport of the context object will be maintained for Drupal 7 such that forward-looking modules may leverage it instead of the existing disparate mechanisms, allowing for cleaner code and a smoother transition to Drupal 8 when the time comes.

The Drupal 7 implementation of the context object will likely be a simple wrapper around the existing functions and globals in many cases. However, as long as the Interface for the object remains consistent between the Drupal 8 core and Drupal 7 contrib implementations that is not a problem.

Step 5: Extended context

A registration system will be provided to allow modules to register components with the context object that will answer additional contextual requests on demand, such as:

• Current Organic Group(s)
• Current user-blog
• Book module navigation location
• Forum hierarchy
• Any others that a module chooses to register itself for.

The exact mechanism for such registration has not yet been defined. The context object will be responsible for ensuring sane defaults are returned in unusual cases or if a given additional context is not registered.

The Services module for Drupal 7 may serve as a testbed for this effort, as the maintainers have indicated that it would greatly simplify their implementation.

Discussion points

• Is the "context stack" a good middle-ground between "global pile'o'crap that's still surprisingly flexible" (current Drupal) and "pure OO dependency injection theory that is 10x more testable than what we have now"? Or is it too complicated?
• If it's too complicated, what's the alternative?
• How exactly does the registration system for extended context work? If two modules try to register themselves at the same time, for the same piece of information, how do we resolve that?