I recently created my first #Drupal@ViewsField plugin, which apparently is unique among plugins in that you also need to implement a hook (hook_views_data_alter) to tell Views about it and how to use it. The properties you define in the hook seem very similar to what other plugins take as annotation.
Is there something especially complex about this plugin type that regular annotation isn't enough, thus the hook? Or is this just a case of a plugin type that COULD be simplified but hasn't yet?
I tried searching the internet, and the Drupal Core issue queue, but I didn't find anything useful. So, I'm turning to the Federated Hive Brain to see if y'all have any better answers!
@DaleTrexel The Views API is a mess. I don't know anyone who doesn't think so. I think a lot of the reason why is that it's absolutely littered with complicated legacy code that can't be ripped out or deeply refactored, because someone somewhere is depending on it. Views is so sprawling and complex that cleaning it up would take years, factoring in the need for the core developers to respect backwards compatibility. I could go on, but you get the idea...
@phenaproxima@DaleTrexel it could also be that invoking Views early in the bootstrapping process overrides the normal operation of low level system processes. I recently created a module that 404's out of range pagination errors. To do so, I created an event subscriber that would execute the Views query early to determine if we should skip rendering and go straight to a 404.
I wanted that to run as early as possible to avoid any unnecessary overhead, but I ended up having to push it toward the end because when it ran early, it interfered with session variables that affected theme rendering.
@DaleTrexel I don't have an answer to this, but I love that the Drupal community is moving away from the walled gardens our questions and conversations helpd build to new open source, open standards based social options!
Add comment