Problem/Motivation
There is a method on ViewExecutable called getMenuLinks(). Its supposed to return menu links provided for the view, but technically this just doesn't make any sense, because
it always depends on the current display, and its not the responsiblity of the view executable to deal with it.
This is also only used ONCE in \Drupal\views\Plugin\Derivative\ViewsMenuLink.
Proposed resolution
Remove the function and instead use the existing methods on the display plugins directly.
Remaining tasks
- Move getMenuLinks from DisplayPluginInterface to DisplayRouterInterface, or a new one?
- Remove ViewExecutable::getMenuLinks
User interface changes
API changes
You can't no longer call getMenuLinks() on every display, but it never made really sense.
Additional new interface DisplayMenuInterface
Beta phase evaluation
Issue category | Task, because it fixes a stupid API and makes things sane |
---|---|
Issue priority | Normal, because the impact is not high |
Disruption | No disruption, because noone will call that method anyway in contrib |
Comment | File | Size | Author |
---|---|---|---|
#23 | interdiff-2498785-23.txt | 757 bytes | damiankloip |
#23 | 2498785-23.patch | 7.06 KB | damiankloip |
#20 | 2498785-20.patch | 7.02 KB | damiankloip |
#13 | interdiff-2498785-13.txt | 534 bytes | damiankloip |
#11 | interdiff-2498785-11.txt | 1.81 KB | damiankloip |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedComment #2
damiankloip CreditAttribution: damiankloip commentedSomething like this.
Comment #3
damiankloip CreditAttribution: damiankloip commentedTalking to Daniel, moving this to a new interface if probably the best idea.
Comment #4
dawehner.
Comment #6
damiankloip CreditAttribution: damiankloip commentedAdded DisplayMenuInterface. No interdiff...because.
Comment #7
damiankloip CreditAttribution: damiankloip commentedComment #8
dawehnerLooks great for me. Added a beta evaluation
Comment #10
jibranFatal error: Call to undefined method Drupal\views\Plugin\views\display\DefaultDisplay::getMenuLinks() in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php on line 2421
Comment #11
damiankloip CreditAttribution: damiankloip commented?
Comment #13
damiankloip CreditAttribution: damiankloip commentedgah
Comment #14
dawehnerThank you for fixing the fatal ;)
Comment #15
damiankloip CreditAttribution: damiankloip commentedMost welcome :)
Comment #18
dawehnerMeh
Comment #19
alexpott2498785-13.patch no longer applies.
Comment #20
damiankloip CreditAttribution: damiankloip commentedRerolled.
Comment #21
damiankloip CreditAttribution: damiankloip commentedComment #23
damiankloip CreditAttribution: damiankloip commentedWe need to init display now that #2497017: Views::getApplicableViews() initializes displays during route rebuilding etc. is in.
Comment #25
dawehnerStill applies.
Interdiff looks fine.
Comment #28
jibranComment #31
tim.plunkettComment #32
xjmThanks, this looks like a sensible fix to me overall. Thanks also for the beta evaluation.
So I think we at least need an inline comment explaining why the base implementation is empty. However, it also makes me wonder if this method should also be on a separate interface if all display plugins don't actually need to implement it?
Also, looking into this further, I noticed that
\Drupal\views\Plugin\views\display\Block::remove()
is still callingparent::remove()
, which is now a null-op.I thought about whether this should include a change record for the BC break. Given the assessment in the beta evaluation, maybe not, but maybe we should add one since there is technically a BC break, it was a public method on ViewExecutable, and maybe someone somewhere has some views menu manipulating code we didn't think of? What do you think?
Also gah at the testbot failures; looks like this issue got stuck in the eddies of the RTBC queue for a month.
Comment #33
dawehnerThank you for your review xjm.
Well you know of our gigantic display plugin objects. Having empty base implementations there is no uncommon. ::execute() , ::newDisplay() are two examples for it. I see your point,
but I'm not sure what we would really from an additional interface at this point, given that there is no way you could start from scratch when you write a display plugin.
In an ideal world I think we should have marked those stuff as @internal. Its just an implementation detail that the view executable was called to generate the menu items.
And there is obligatory smiley :)
Comment #34
damiankloip CreditAttribution: damiankloip commentedNo, I think I agree this is not really interface material. We then need to always check for another interface and that seems worse DX and more error prone. As much as people have tried to shoehorn new interfaces into views plugins, they are still basically dependent on the base class for a plugin type, especially displays.
I would imagine close to zero people will be using that, but sure, we could add a notice anyway. Can't hurt.
Comment #36
dawehnerIts still green.
Comment #37
damiankloip CreditAttribution: damiankloip commentedCreated a CR here: https://www.drupal.org/node/2540418
Comment #38
alexpottCommitted 3c12e21 and pushed to 8.0.x. Thanks!
Thanks for adding the CR and the beta evaluation.