Views for Coders at Drupalcon Chicago

 

by Karim Ratib, infojunkie on d.o. He's the author/maintainer of Views Bulk Operations, Views Hacks, Sheetnode, Feeds Oauth, and Feeds Topics. He's currently a freelancer living in Vancouver.

Objectives

To give you a conceptual overview of how to code views, without going into the details, which can be a bit overwhelming. We'll be talking about high-level stuff. Hopefully by the end of the talk you'll be able to open some Views code and maybe even start coding your own views.

Coding node lists is boring. Coding node lists with filters and different themes is very boring. Views helps with this! Views first checkin was in 2005, and contains almost 100,000 lines of code, and there are over 400 third party sub-modules! It's so successful, it has spawned this whole module ecosystem. It is the most-used module right after Drupal core itself.

Views is an SQL query generator and renderer.

It builds SQL queries, and then renders the results onto a page.

Architecture Overview

What would we do if Views did not exist? We'd write up a bunch of SQL to select the node information, implement a hook_menu() to create a path, and then call theme('table', $results).

Views has the concept of the base table, which is the entity that Views deals with most. In our example, this is the node table. This base table is usually joined with the users table. In views, this is called relationships, which gives Views the information about how tables in the database are related to each other.

Filters in Views correspond to the Where clause. Arguments do as well, except Arguments get their values from some external input, such as the URL. We also have Sort in views, which corresponds to the Order By in SQL.

All these Views terms have their own areas in the Views UI where you can manipulate them through a graphical interface.

View Components

Each View has a Query object, which is responsible for building up the SQL given the config that we do on the user interface. The Query object has a Pager which implements the paging mechanism.

The other important object that Views contains is Displays. Each Display has a number of settings, including the style and fields that are being rendered. Each Display also has Handlers and Plugins.

Each Display can be a Page, Block, or Feed. Displays can also be associated with Plugins, which can be a Style, Access or Cache.

Style Plugins determine how the view is rendered on display. Access Plugins determine access control, and finally the Cache Plugin determines how the view is cached, if at all.

The Views module goes through three main phases of execution:

Phase 1: Build

  • Init components
  • Get arguments
  • Generate SQL

view::build()

Phase 2: Execute

  • Execute SQL
  • Store result in array

view::execute()

Render Results

  • Execute theme functions

view::render()

In addition, Views provides a lot of opportunities for third-party modules to alter the way Views works at every step of this execution pipeline. At every stage, there is a hook that's invoked before the stage is executed and another hook executed afterward. These are useful because they allow third-party modules to do whatever operations they need.

File Structure

  • views/ : Drupal facade

    • includes/: core: view, query, base classes
    • handlers/: SQL add-onsL fields, filters, arguments, relationships, sort
    • plugins/: non-SQL add-ons: display, style, row, arg default, arg validator, access, cache, query (3.x), exposed form (3.x), pager (3.x)
    • theme/: theme and preprocessor files
    • modules/: data models and specialized handlers
      • node/
      • user/
      • taxonomy/

Examples

views_block is a block that exposes Drupal block data model to Views. I wrote the required metadata and handlers to display block information using views.

  • views_block_views_api() is important because it tells Views what version we're using.
  • views_block.views.inc is important because it contains the metadata of our tables. In this case, we're going to expose the boxes and blocks table so that Views knows how to build a query to select data out of them.

FAQ

Can we modify the SQL after it's created?

Yes, just implement hook_views_post_build(), and you'll get a copy of the SQL statement, which you can change. The problem with that approach is that we would be modifying a fully-formed SQL statement, and we'd need to parse it again. Because Views is so flexible, it calls a great number of hooks such as views_query_alter(), which gives you the query object, which you can manipulate to add and remove clauses.

Did you enjoy this post? Please spread the word.