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.
Comments
Meeting notes
Highly relevant discussion here: http://groups.drupal.org/node/70738
Please read it for context in this thread. :-)
Crell, is this within the
Crell, is this within the scope of D8 and does it relate at all to chx call the action to tear block module apart
In particular the bit about providing a UI (a new UI I assume, or perhaps he just means shifting the current UI into block_ui?).
Bleeding somewhat into the discussions on plugins how might Blocks TNG impact themes - for example could themes have layout plugins, such as Panels supports right now - this would be very cool, as would the possibility to support style plugins also (aka Skinr/Stylizer sorts of things) which apply to a context (context + layout + style = awesomsauce).
What I'm trying to get a handle on here the broad scope/directing of Blocks TNG and if its within the scope of D8. I can see a lot of challenges for themes in D8 and this could potentially provide solutions, or at least provide a strong direction for D9 if groundwork is laid in D8.
Hopefully
I cannot speak for chx, but yes, replacing the current craptastic block system with a Panels-inspired Blocks TNG is part of the roadmap. There are several steps to get through before we get there, however, so whether it makes it into D8 or has to wait for D9 depends on how much we get done in what timeframe. :-)