solved a problem for views that we should really be solving more generically: providing an avenue for the block plugin to make an initial suggestion about what the machine name for an instance of that block plugin should be. i'm happy we got it in, i just think we didn't go far enough. and that we also got some responsibilities slightly mixed up.
this patch fixes both the responsibility mixup and makes it go whole hog: it adds a
getMachineNameBase() method to
BlockPluginInterface, implements it on
ViewsBlock, removes the one-off method from
ViewsBlock, guts most of the icky sticky
views_form_block_form_alter() implementation, gets
BlockFormController to utilize the new
getMachineNameBase() method, then keep appending shit to it until it comes back unique in the exact same way the one-off ViewsBlock method used to do it.
it also removes the corresponding views test entirely. this is temporary. since the id-getting method is no longer is solely on
ViewsBlock, but now incorporated onto
BlockPluginInterface, then the corresponding test should also no longer be a Views test. i haven't written that test yet - at the moment, i just wanted to get this up to see what else breaks.
this is good because it means that block plugins are, once again, divorced from information about their storage. this makes princess happy because there, not all blocks are standalone, which means their uniqueness cannot be accurately determined by the block storage manager. the responsibility for determining uniqueness is instead left in the hands of the form controller, where it belongs.
The BlockFormController implements a constructor to inject the module handler,entity manager, and query factory services. These are injected using the static
createInstance() method from the container during instantiation by the Entity manager.
PASSED: [[SimpleTest]]: [MySQL] 57,913 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 57,822 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 57,183 pass(es). View