Problem/Motivation
When you create a views area plugin (e.g. things you can add to header, footer etc), you still have to add a corresponding entry in hook_views_data()
in order for it to work.
Proposed resolution
Add additional properties to the @ViewsArea plugin - label and desription.
Have views_views_data
populate the entries on behalf of plugins that provide those values.
Eventually, remove the need for having the entry in hook_views_data
and just use plugins.
But in the meantime, we need to maintain backwards compatability.
Remaining tasks
The lot
User interface changes
None.
API changes
Will need to maintain BC. Plugins that provide a label and a description won't need to also add an entry in hook_views_data
Data model changes
Changes to hook_views_data
Comments
Comment #2
dawehnerThere have been historically two reasons why area thingies are handlers
a) We wanted them to be accessible just for certain base tables. We had for example the idea to have a plugin for just node/add links
b) We wanted to be able to initialize multiple of them. The views plugin infrastructure in
DisplayPluginBase
currently doesn't allow thatConceptually I totally agree though, area thingies shouldn't really be handlers.
Comment #3
larowlanFor a) in theory we could add something like allowed_tables to the annotation, like we do for field_types with formatters/widgets.
for b) are you saying it didn't end up that way anyway so doesn't matter?
Comment #9
amjad1233@larowlan for "For a) in theory we could add something like allowed_tables to the annotation, like we do for field_types with formatters/widgets." can you point me to an example ?
Really wishing to smash this one.