One of the things we did in
BlockBase::build(). This was not the greatest thing.
- It places responsibility for dictating how the presentation layer should receive the block into the hands of the block itself. Block plugins should be concerned only with producing a) a title, b) content, and hopefully soon c) assets. They should not concern themselves with how that information is glued together and provided to the frontend. We have a BlockPluginInterface specifically so that external systems can make such decisions.
- By placing the alter inside the build method, we make it possible for blocks to individually decide whether they are alterable or not. Much though I hate that particular alter, if we're going to have it, then it needs to be invoked reliably. That means pushing the decision up to a higher layer where it can be swapped out wholesale, and is either on or off for all blocks, equally.
- If someone wants to, say, create an administrative interface in which one "renders" blocks for some alternate purpose - say, putting in dummy content in order to populate a demonstration interface - then it's easy to do by simply swapping in a different rendering controller and creating a different default render array. If the logic remains baked on the block itself, though, then we either have to ignore that method entirely, or throw out and rewrite most the render array each time...and it's hard to do that really reliably, since a particular block plugin might override BlockBase::build() and do a whole buncha wacky crap with the render array it returns.
So, this patch shifts that responsibility back out onto the
BlockRenderController. It also gets rid of the
blockBuild() method, and all block plugins now just directly implement
Note: this also makes princess happy.
|PASSED: [[SimpleTest]]: [MySQL] 55,044 pass(es).|
|FAILED: [[SimpleTest]]: [MySQL] 55,431 pass(es), 9 fail(s), and 177 exception(s).|
|FAILED: [[SimpleTest]]: [MySQL] 55,050 pass(es), 1 fail(s), and 0 exception(s).|