As discussed in #2772745-19: Search API integration doesn't check/define feature support of backends, search displays should be able to define their dependencies. We can either do this by adding the DependentPluginInterface
right to the search display interface, or by just implementing the interface with those plugin classes that we define. The former would probably be better as it would motivate developers to also add proper dependency information for their plugins. (Also, in the plugin base class, we could already add the index by default – I guess in any case, even if not adding the interface right to ours.)
One problem with the Views search displays is that I guess there's no way to depend on an actual Views display, which we'd actually need – we can just add the view itself as a dependency, and live with this maybe causing trouble sometimes. (Unless someone more clever than me comes up with a solution.)
Comment | File | Size | Author |
---|---|---|---|
#9 | 2831436-9--display_plugin_dependencies.patch | 5.96 KB | drunken monkey |
|
Comments
Comment #2
borisson_I'd say we go for the first option. More strictness is a good idea there I think.
I've broken my head over that a few times already. I have no idea how we can do that, so I guess for now we should just add a dependency on the view.
Comment #3
borisson_I'll have a look at this issue over the weekend, this is something I'd love to see included in the next release. We should probably ping someone with more views experience about a way to do dependency on a views-display.
Comment #4
borisson_This should get a test as well, and I haven't tested it. Started on this too close to heading out for beers.
Hopefully I can find some time to work on this on sunday.
Comment #6
drunken monkeyThanks for starting on this!
The base class shouldn't really have the code to deal with a view dependency, though.
And while asking a Views expert can't hurt, I really don't think it's possible at this point. (At least without introducing something like fake display config entities.)
Here is my suggestion.
You're right, though, it still needs tests in any case. But thanks again for the work so far!
Comment #7
borisson_I like that, let's see how the bot feels about the patch in #6
Comment #8
borisson_Comment #9
drunken monkeyLooks good, thanks!
If the bot agrees with this slightly changed version, I guess I can commit it.
Comment #10
drunken monkeyCommitted. Thanks again!
Comment #12
borisson_hah, cool. I didn't know about
assertContains
! Thanks Thomas!Comment #13
borisson_Back to fixed per #10.
Comment #14
drunken monkeyI thought as much, yeah. It's a bit confusing, since it doesn't have
Array
in the name and can also be used to check for substring matches. (And there's no second, dedicated method for either of them.)