Not much has changed here since it wasn't much discussed. I am just expanding on it based on the presentation at the SF Dev Summit that I didn't include before because it was after 3 am by the time I was writing this section originally.
This phase involves implementing a new block-centric Response object using the system developed in phase 2. This system is intended to replace the hook_menu-based implementation. It will also by nature provide support for block-specific AHAH responses.
This will involve conversion of blocks into classed objects with configuration objects, inspired by Panels Content Panes. It may be advisable to rename blocks to "components" or some other name in order to provide more designer-friendly terminology. The net result of this phase includes considerably more power in core as well as a layout mechanism that is closer to common designer workflow.
The Response object will be responsible for selecting a layout (based on information retrieved from the context object, such as node type, user configuration, and various other inputs), the blocks present in that layout, and the configuration of each block. Each block will be rendered in turn and its output placed into the layout, which will then be returned.
A Block that also supports a layout is called a Region. A Region also includes a layout, Blocks, and configuration for those blocks. When rendered it will act the same as the Response object, returning an HTML fragment.
Blocks and Regions may nest to arbitrary depth.
Any Block may be cacheable in a configurable way. If a Block is cached, by implication so are all of its sub-Blocks if applicable. Side-band information (HTTP headers, CSS and JS files, etc.) must be cached along with the rendered output of a given Block, including nested side-band information.
Discussion points
- Every system seems to define its own terminology for these renderable chunks, none of them compatible. Should we go with a generic name, or something deliberately Drupal-specific? What about "Droplets"? :-)
- We must have a way to persist this configuration to code. Exportables in their current form are insufficient. We need something considerably more powerful to allow this sort of configuration to be persisted to code in a meaningful way.
- How much "sideways configuration" do we need to allow? By that I mean "this block goes in this region in this layout, with this configuration" vs. "this block goes in this region on these 4 layouts, with this configuration." I am not entirely sure how we'd do that. I am sure sdboyer will chime in here.
