It would definitely be helpful to have an overview of the Views building process. I am not sure how in depth it should be. There are two approaches that I can see currently:

  • The Mileses have a "Life of a View" section in the rough cut of their upcoming book. It is fairly high level, not describing how different plugins and handlers work in particular, but rather talks about the general process.
  • I have also started some documentation, which I will post below. It describes different plugins as they are attached and what data from the user interface is used at which points.

I'm wondering whether there is a need for the in depth documentation that I'm building (do people find it useful?) and what the right place for it would be. I am thinking it might be best in the handbook, somewhere in the structure that arianek proposed in #673228: Clean up Views section of handbook.

Comments

Anonymous’s picture

Initialization

When a page containing a View is first requested, it will call a callback such as views_page or views_block. These, in turn, trigger display plugins, which is the entry point for Views execution. As the plugin documentation says, “Display plugins are responsible for controlling where a view lives.” For instance, whether it lives on a page or in a block.

The callback calls the display plugin with this line:
$view->execute_display($display_id, $args);
The different callbacks retrieve the $view and $display_id in different ways. On the page, the $view’s name and $display_id are stored in the database as page_arguments. In a block, the $view’s name and $display_id are taken from the delta of the block. The view is loaded using the $view name, and the appropriate display is executed.

In execute_display, the display handler object is attached to the view.

The view’s pre_execute function runs, which renders and attaches any other Views which are attached to the current one. It also allows modules to modify the view object before rendering by using hook_views_pre_view and it runs the display handlers’s pre_execute function to allow the display plugin to do whatever it needs.

Then the view executes the display plugin.

Pluggable: Display Plugin

The display plugin can be one of the defaults (page, block, feed, and attachment) or it can be one defined by a module. Display plugins create the appropriate data structure to hand back to the caller and can also perform other preparatory functions.

For example, views_plugin_display_page sets the page title and the breadcrumb before rendering the view. views_plugin_display_block creates the array that the block expects, setting $info[‘content’] to the rendered view and $info[‘subject’] to the view title.

To render the view, the display handler object calls a function on it’s view object, $this->view->render() which calls $view->execute() which calls $view->build() to build the query.

Link to Create your Own Display Plugin Documentation

Building the Query

Hookable. The build function allows modules to change the view before it builds the query by using hook_views_pre_build.

The build function then initializes the query with $view->init_query. This sets the base table, field, and database (optional). These values are stored in hook_views_data and the user selects which to use when creating the view on the Add View page. The query options that the user has set in Advanced Settings > Query Settings are retrieved.

Picture of Add View page with additional selection. Caption: Additional View types can be added with Query Plugins.

Then, the function creates and initializes the query object. If a different kind of query, such as a SPARQL query, was chosen, a query class will be defined in hook_views_data by the custom query plugin, and that query class is used. Otherwise, the default views_query is used. The query object is attached to the view and the init in the query plugin is executed.

Pluggable: Query Plugin

iamjon’s picture

I ran across this on the interwebs/d.o, thought it was relevant to the thread. (Thank you moofie.)

http://blue.live4all.co.il/~mooffie/tmp/views_illustrated/views_life.html

I'm not too sure that it's gpl, so we might need to ask moofie if we would like to incorporate it.
I don't know how much has changed in views since it was created.

esmerel’s picture

Can we turn this into a real patch? That'd be pretty helpful. :)

Anonymous’s picture

Do you think that the content is actually useful? I wasn't sure whether or not it is too low level.

merlinofchaos’s picture

Yes that seems useful.

esmerel’s picture

Honestly, it's hard to have "too low" of a level for documentation. :)

dawehner’s picture

Somewhere in the issue queue is a patch with a short description of the lifetime of a view, though as always finding everything in the issue queue is hard.

MustangGB’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)