Here is what got written up:
There are three critical components of the system
- RequestContext allows you to ask questions about the current context like, "What is the current language?", "What is the current user?" The RequestContext will functionally take the place of a scattershot of drupal elements like global
$user,$language,menu_get_object(), etc. - RequestDispatcher will be responsible for taking the initially built context and determining how to route a request on the basis of that request context.
- RequestHandler will be responsible for taking a fully built context object and generating a response, e.g. HTML output, JSON, etc.
RequestContext
The RequestContext will utilize a registry of items that can be part of the context. Each is essentially a "question" that can be asked of a RequestContext. Some implementation ideas:
- Store registered callback/plugin/whatever entry in the database with an additional flag for whether the item should always be loaded or may be lazy loaded
- Provide sensible defaults in the case that there is no available answer for a context question, e.g. "What is the current user?" falls back to the default of
anonymous user
List of possible context items:
- Current User
- Current OG
- HTTP header
- Current language
- Session
- Current loaded entities
- Book
- Pager state
- Forum
- Conf
- Path
- Domain (for multisite and/or domain access)
Output type (ex. RSS vs. JSON vs. HTML)never mind, this is part of HTTP header
The bolded ones are required, meaning they will be loaded every page load, and non bold are lazy-loaded.
(Is this the right place to suggest a primitive 'container' object (or property of the context object?) of which OG, Book, and Forum would all be examples? ~matt2000)
RequestDispatcher
Decides what page we're on. Currently, that's the menu router system. We could potentially we could swap it out - a good use case would be the installer.
To note about the menu system. If we have something like taxonomy/term/%term - somehow that %term needs to be injected into the context.
RequestHandler
@TODO
Tasks
- crell will be writing up a more detailed specification of the Request architecture
- crell solicit feedback from Services folks for needs & design of RequestDispatcher
- Code the RequestContext base object
- One patch at a time, convert hard-wired contexts (as listed above) to this object using functions - context_get, context_set. Also, change hook_menu to shove into the context.
- Goal: implement a simplified/limited RequestDispatcher in
install.phpas proof that the same request system can be used for limited edge case bootstraps in Drupal - Goal: start with a global/singleton RequestContext, eventually move toward contexts that are passed explicitly to allow for unit testing, encapsulation