|Issue tags:||Dynamic layouts|
The layouts patch (#1787846: Themes should declare their layouts), as it was committed, creates configuration objects that were never intended to be anything more than "layout configuration" - that is, how blocks are arranged into regions defined by a layout. You pair that config with a layout plugin, and you have a layout plugin instance.
Thing is, that's not flexible enough to meet our needs. For one, that approach tends to rely on static mapping of blocks to regions; however, given that one of our goals is the ability to dynamically (at some level) swap out layouts, it makes more sense to abstract the storage a bit and include information about the region 'role' (issue: #1816968: Introduce region 'types' to layout spec). This ends up meaning having layout plugin configuration...without a layout plugin.
We should create a different type of config object that can exist independent of any particular layout plugin, whose responsibility is to be the canonical way of describing page composition. In Panels, we have historically called these things a 'Display', and I've stuck with that terminology for now.
The primary place this terminology clashes is with entity rendering/view modes & field UI. The current plan (roughly agreed to by the relevant parties so far) is to solve that problem simply by using the same Display class for all of those things. In other words, top-level renderables that are configured via the UI are all, always blocks, and can be placed into layouts. That's not actually as crazy as it sounds :)
For the initial implementation, we should create a
ConfigEntity subclass called
Display, and a
DisplayInterface that describes its behavior. These config objects should contain a reference to a layout plugin (and any relevant configuration that is specific to that layout itself), references to block plugins and their configuration (which will have to be retrieved via subsequent calls to
config()), and information about the placement of those blocks within the layout's regions.
The expectation is that these Display objects are what will be produced by anything that wants to build a page - for example, the system being worked on in #1787942: Allow assigning layouts to pages. There are a number of ways we might expect they'll be used to do the job of displaying a page, or some sub-page element (if used in field UI), but the expectation is that whatever system creates a Display should save it at some config address that some corresponding system will be able to find later in order to render it. The evolving pattern for doing that in the context of rendering the entire page is in #1812720: Implement the new panels-ish controller [it's a good purple]. This patch originally lived there, but we separated it out.
Mostly we need to talk through the interface a bit more and make sure it covers the initial use cases we can imagine. Displays will not really be functional, however, until #1535868: Change notice: Convert all blocks into plugins is in, as they need a standard way of addressing block config (and possibly even doing block instance retrieval, though that's unlikely).
User interface changes
No UI changes, this is entirely API level.
Layouts need to adapt to expect Display objects instead of the configuration format they had before.