Create pluggable display extenders

This is one of the things the Views architecture is really poor at, and so there isn't currently a mechanism to do that.

Displays own most of the settings that a View uses, and inherited displays get to add or remove them as they like. Because of the inherited nature of the settings, it actually turns out to be difficult to create a system where you can extend this. (This is one of the arguments in favor of the hook system. It extends horizontally very well, but not so much vertically). So sadly, there is currently no way to do this without creating your own display.

It is a feature I hope to tackle at some point for Views 3, though it will likely be a little bit complex.

Setting to active task. This is one of the big features I still want that has never been addressed.

My architecture looks like this.

There is a new plugin type, 'display_extender', and it uses more or less the strategy pattern.

views_plugin_display::init() will get all existing display extender objects and instantiate them.

Key functions on views_plugin_display would then call through to the extenders. For example, something like:

function option_definition() {
  // .. regular option definition code here
  foreach ($this->extender as $extender) { 
    $extender->option_definition();
  }
}

(The above is just pseudo code, it ignores arguments).

We would need to carefully examine views_plugin_display and figure out which methods need to implement this, but it's mostly the options, options form, query and rendering methods.

One part of this patch should be to be able to instance plugins multiple times.

Assign to myself for now.

Here is an initial version. Many things like options have to be figured out etc.
At least in works for options_summary, see picture.

sub

Change title

There is currently a problem: option_definition doesn't work. Here is an explaination:

The extenders get's loaded on display::init. Therefore unpack_options had to be runned already, because the options are needed here, to get the enabled extenders.

But to run unpack_options you need the option_definition, so the call to the extenders will not happen, because they are not initiated yet.
Does someone has an idea about this?

There is a construct() method that runs prior to unpack options, I believe.

Subscribing...this is likely how we'd properly integrate Metatags with Views.

Here is a new version which works fine without any problems for me.

This time it would be cool if someone could really review it :)

Let's stick with the current views usage: $view->field, $view->argument etc.
Additional i took this from http://drupal.org/node/681468#comment-4381388

This is awesome.
The patch is small and easy to understand. $this->extender feels a bit weird (as justin noted) ,but since it's a views convention, I'm fine with it.

Can we do it for handlers next? :)

I think for handlers the performance implications would be very very bad. There's a LOT more handlers running during a view than there are displays, and I'm already concerned that a bunch of display extenders will slow the system down just by being present.

In handlers, they definitely would.

Commited a slighly improved version to d7.

This needs some work for d6, because there is no class registry availible.
Please test the feature and create some real world use cases.

Don't plugins handle this by having parentage defined? Or did you make these not true plugins?

This are true plugins.

But at least the .info file has to be changed and there was no motivation yesterday evening.

@dereine: Do you have your sample chucknorris display extender posted somewhere? I'd love to take a look at how the final version looks from the integrating side.

It's here: http://drupal.org/sandbox/dereine/1135860

It works like every views plugin, so option_definition/options_form can be used, but you have to use options_summary to provide the links to the user and you have to store the value via options_submit

OK, I can get to the place where my summary displays. Creating the plugin was simple enough, figuring out how to enable turned out to be much more difficult. You have to go to the Views Tools >> Advanced page to see an option to enable your extender.

Does this mean neither a module nor a default view can control if that is enabled? I want to use this for Calendar to replace the custom displays (which exist mostly so I have a place to define settings like this.) But it appears it won't work unless I instruct all the users to go to Tools >> Advanced to enable it? I'd prefer to have something that can be pre-set in an exported or default view, or set by the module that creates the extender. Maybe I'm missing something or maybe this is just because it's too new to let anyone see it yet and in the long run it will go somewhere else?

I'm also trying to figure out if there is a way to control *where* these settings show up. They don't make sense everywhere, only on calendars. I really don't want to see them on every display of every view.

I'm glad to see this functionality, I am starting a total rewrite of Calendar and ditching a lot of the Calendar hacks that were needed in older versions of Views, so I'm trying to understand how these plugins are intended to be used.

In general it's stored in a variable so if you really want to enable it, you can.
In general display extenders can only work globally, due to the chicken and egg problem, see http://drupal.org/node/681468#comment-4384814

Additional you can check for things which exist on the view in the options_summary method.

In general you should talk with EclipseGC who tries to rewrite calendar based on a pager plugin which seems to make more sense for me. You can also define custom option, but you can take control over it as well.

This is different than the pager issue. I am rewriting calendar to use row plugins and pager plugins and whatever else I can find to use, but I was using custom displays to set global settings since there is no other place to do it.

OK, the display extender may not be the solution I was looking for. Just to clarify for anyone else who's trying to understand it, it is for additional settings that you DO want on every view.

initially i hoped to make it per view, but i have no idea how to do so.

LOL, if YOU don't know how to do it, I suspect it is pretty hard to do :)

Ported the chuck norris module to d6 and tested it with my port of this patch. It worked fine so commited. Yes, now it makes fun again to work on d6 ;)

Just a random quote
The original draft of The Lord of the Rings featured Chuck Norris instead of Frodo Baggins. It was only 5 pages long, as Chuck roundhouse-kicked Sauron?s ass halfway through the first chapter.

Hrm, a follow-up since after attempting to use display extenders I'm not so sure they're the answer: #1278534: RFC: Replace views display extenders with drupal_alter() calls inside views_plugin_display()