Convert install.php, update.php, authorize.php and similar alternate environments to use a custom response and context objects. This will provide a substantial simplification of all of the above systems.
Potentially a "detect broken state" check could also route off to a special maintenance mode response object.
Discussion points
- Should these Response objects be just subclasses off of the main HTML page Respose object, or is there something legitimately different about them?
- If we want to use alternate context or response objects for handling minimal or broken states, does that mean certain hooks (theme and menu at least) must go through the context object so that they can be faked out for those cases?
Comments
It looks to me like these
It looks to me like these need different dispatchers.
At least going back to what I said in Phase 2 - http://groups.drupal.org/node/67588#comment-204763 (which may be completely wrong), response objects would be often subclassed. So install.php may contain several response objects (one for each page). The dispatcher in install.php would be able to figure out which display controller (and thus response object) to get.
This has the potential to be awesome. For install profiles to add extra steps in the installer, they'd just swap out the Dispatcher.