as this code is still quite entirely pseudocode, i'm putting it over here rather than directly in the core queue. I'd like to get it there ASAP, but not just yet.
i've pushed up a new branch to this repo called 'booze'. it contains the first pass at putting together the panels-ish controller that connects WSCCI with Scotch. it also has the patch fromcommitted to it, and should have the latest from committed to it as well. b/c, yknow...that's basically blocks and layouts.
first, let me note that i've used names like 'Drunken' and 'Booze' throughout this code. i'm expecting these will change, of course, but in the absence of better, permanent names, it seemed appropriate to do since we're sort of bridging the two initiatives here.
the names do serve an important discussion purpose, too: it gives me an easy way to say "if we're serving a boozey/drunken page", which is more comfortable than "if we're using a blocks-and-layouts approach to serving the page."
there are three major components to note right now.
Drupal\Core\Config\Entity\Display class. this class, entirely analogous to display objects from Panels, encapsulates all configuration for a given boozey route: the layout instance (so that's plugin name + conf, if any), all block instances (again, plugin name + conf) that are in use for the page, AND meta-conf that is not specific to any of these (e.g., which regions and in what order the blocks should be placed).
the Display class extends
ConfigEntity. i went this route for two basic reasons: a) it's by far the easiest way to allow a specialized config class (which we need in order to provide certain data organization, abstraction, and lazy loading mechanisms) that can take over a certain config namespace prefix, and b) because ConfigEntity provides us with revisioning support. i'm far from settled on the decision to use
ConfigEntity; i dislike not accessing config info through
config(), and i'm not convinced that the revisioning provided will be useful for the task we need it for. there's already an issue that's roughly about this, and i just updated it with my additional thoughts on divergent config history: .
the class is currently a shell with none of the methods implemented. there needs to be a lot more logic in there, and there's also some issues (can be discussed later) about ways we might want to mutate behavior by manipulating what's in the $display. most of the manipulations, however, should happen at compile-time, NOT at runtime. runtime modifications can easily destroy page predictability, break contracts suggested by the UI, and break caching. probably the biggest compile-time manipulation we'll need to make is managing globalish block injection driven by the replacement to admin/structure/blocks. that's a tricky question no matter what, and it gets into how we
i do not have a sample version of all the config i expect to be contained in one of these display objects written up yet. it's at the top of my list, as it obviously shapes what the interfaces will need to create.
i realize the term 'display' is fairly fraught. i'm open to coming up with something else, but it's tricky. Display is the term used in panels right now to describe this thing.
this subscriber responds to KernelEvents::CONTROLLER, and is how we make the $display object available for use by the controller. its logic is shit right now, but this is the place where we make the foundational decision about what display object (and therefore what layout, blocks, etc.) is going to be used on for the current request. at the moment, the binding is very simple: it looks for
"booze.display.$routename" - that means one display per route, and one route per display. this is probably not what we'll eventually do (we may not even settle on just one thing eventually), but it works for now. it's also the best answer to the basic being asked in .
there's a small modification to the existing RouteProcessorSubscriber in order to point to the new controller. if i had just replaced HtmlPageController instead of created the new DrunkController, then that modification wouldn't have been necessary. we'll get there soon enough.
this is the core of the new rendering approach. what's in there right now is VERY rudimentary, but it illustrates the basic approach. roughly, that approach is:
- render all blocks, passing them whatever context they need (figuring out context is still a big giant gaping hole)
- render all regions, passing them the rendered blocks.
- render the whole layout, passing it the rendered regions.
there are a lot of additional switches & stuff from panels i haven't touched at all yet. styles are the most glaring thing that's missing, but caching also hasn't been touched (that's a wider issue anyway, and has to do with how we do the block rendering - subrequest or direct).
for those coming from, this controller pulls out a fair bit of the logic that we had been placing directly in the Layout classes. this, i think, is a very good thing.
this sequence needs discussion. despite the fact that i just went with a simplified version of what Panels does right now, one of the things that took me the most time with this patch was pondering of the various different types of templates we might want to be able to interact with, and how to encapsulate those differences. this basic approach is good enough for Dec 1, but if we're going to deliver on the discussion we had in Munich (a generated template directory), it's gonna mean having more possibilities than just this one way.
there's plenty of other stuff, but this gets us a realistic start at bringing it all together, and hopefully provides a foundation for a bunch of other discussions.
getting this all finally working is also bound up with/blocked on at least the following, in addition to those linked above:
- - if we go the subrequest route for rendering blocks, this pretty much is our caching mechanism. i'm still a little dubious, but as you can see from the pseudocode, there's very little cost (right now) to doing it one way vs. the other.
- - SO much we can do with twig. it's a bit more tangential (technically we can do this with either phptemplate or twig), but i have some eventual goals (very much post Dec 1) that are pinned on twig.
- - a clear prerequisite for all this - we're how layouts now attach, instead of to themes.
- - the question of what blocks attach to is central to everything we're doing here.
- - to me, this is the "how we solve complex routing problems" issue, and until we've got best practices/patterns defined around that, we won't be able to answer the "how do we bind layouts/displays to routes" question very well.
- - until content negotiation is in, we won't have a good foundation for determining when to use the whole boozey system.
- - people defining (most) routes will need to be at least vaguely conscious of what we're doing here, so DX is gonna be bound up with at least some of our choices here. more concretely, if we do blocks as subrequests, that means dynamic routes, which is what that issue is currently discussing.
- - if we go the subrequest route for blocks, this will probably be the system we use to get contextual data into blocks.
|FAILED: [[SimpleTest]]: [MySQL] 50,509 pass(es), 275 fail(s), and 40,144 exception(s). |
[ View ]
|FAILED: [[SimpleTest]]: [MySQL] 51,040 pass(es), 182 fail(s), and 36 exception(s). |
[ View ]