Problem/Motivation
This is a bit of a cleanup task. When you are working with views plugins you sometimes need to see which type of display you are working in.
This is particularly useful when you need a different output format for "data" displays as opposed to "normal" displays.
I've been working on tooling for REST data displays and this is the 5th time i've needed to know if the current display was a "data" display.
I don't see a use case for having a protected getter that doesn't harbor sensitive data.
Proposed resolution
Make the getType method public and add it to the DisplayPluginInterface interface.
Remaining tasks
Create a patch and review.
User interface changes
none
API changes
DisplayPluginInterface will have to implement getType but fallbacks to DisplayPluginBase will already implement getType.
Data model changes
none
Beta phase evaluation
| Issue category | This is a cleanup task. Leaving getType out of DisplayPluginInterface is an omission and it doesn't need to be protected since it's just a getter. |
|---|---|
| Issue priority | Major because it blocks contrib from being able to determine what type of display a plugin belongs to. |
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2562811-3.patch | 4.41 KB | Jaesin |
| #3 | interdiff_2562811_1-3.txt | 2.31 KB | Jaesin |
| gettype.patch | 2.09 KB | Jaesin |
Comments
Comment #3
Jaesin commentedClean up the rest of the display plugins.
Comment #4
dawehner+1 from me
Comment #5
jibranI'm also +1 on the change but this is going to be disruptive for contrib so maybe add a BE with strong argument why we need this and maybe add a change notice as well.
Comment #6
dawehner/me sighs
Comment #7
Jaesin commentedComment #8
Jaesin commentedComment #9
dawehner@jibran
Added as much information as you can get out of this into a change record.
Comment #12
jibranThanks @dawehner. RTBC+1
Comment #13
dawehner...
Comment #17
Jaesin commentedRe-tested to make sure patch still applies. Moving back to RTBC.
Comment #18
effulgentsia commentedAdding credit for reviewers, and thank you, @jibran, for flagging the need for a change record here.
Comment #20
effulgentsia commentedFixing this omission makes a lot of sense. I'm sad to break contrib subclasses, but better before RC than after. Pushed to 8.0.x and published the CR.