"Developing for Views," Aaron Couch: Drupal Camp Twin Cities 2011

If I have a Drupal headache, there is a good chance I am working in Views. Views gives you all the power of the universe, as it is an interface to approximate how SQL queries works. However, when you get into the weeds with things like arguments and relationships, things get complicated: fast.

Thankfully, at Drupal Camp Twin Cities 2011, Aaron Couch presented a session on “Developing with Views.”

Session description:

In this session I will take a look at Views under the hood. We will review some of the basics of Views structure and then walk through adding the following:

Adding a custom database table

Adding a custom filter

Adding a custom argument

Adding a custom row style

Aaron works out of Philly and lives in Madision. On drupal.org, his username is acouch.

And here are my notes:

Is this for you?

You should:

Be familiar with Views I
Comfortable with PHP and Drupal mod dev

Today:

hook_views_data()
views_plugin_validator()
views_plugin_row_style()
import/export

Our project today

Good news: Aaron is getting married really soon. Bad news: Aaron is getting married really soon. (“This is real, guys: This is happening.”
Needs a way to allow people to RSVP
He already has the user data on his site
Doesn’t want to make them sign up again if he already has their info

Form already created

If they are logged in, it saves their uid (user ID)
If not, it grabs the rest of their info
User data is in two places
So what can we do with it?

Data model

Custom table storing:

[name]
[email]
[uid] User ID
[hotel] Hotel they are staying at
[meal] Food they want to eat

Could use entities, which have a UI, but we wouldn’t get to use hook_views_data, which should be fun.

This table is created through a custom module.

Drupal objects

$user has:

full_name
status (are they coming?)
photo

$nodes

meal/hotel
photo

Enter views

Think of views as lists.

Views contain two basic objects:

views_db_object
views_object
- Define data: fields, conditions, ordering (handlers)
- Output data: process and display (plugins)

Making a list: views as a query engine

SELECT example.name, users.status, users.mail, hotel.title, hotel.photo, users.photo
FROM example example
LEFT JOIN user ON example.uid = user.uid
WHERE users.status = 1
ORDER BY example.date

That is the traditional way to talk to the data tables outside of views.

Translating quueries: Views UI

Choosing what type of info you want for your views, such as Nodes or Users = WHERE
Fields = SELECT
Filter criteria = WHERE
Sort criteria = ORDER BY
Arguments (now Contextual filters) = WHERE
Relationships = JOIN

Telling views about our data

hook_views_data: Define custom tables
hook_views_data_alter: Expose new fields to table from another module

To tell views about our custom data, we start by using hook_views_api. We took a brief look at the views API.

It was around this point that I realized that the way hard-core developers interface with Drupal is far different than how a site builder like me does.

I really don’t understand why we are creating a custom table and why we are creating a module to work with views rather than using nodes and the views user interface. Frankly, that’s what I thought this session was going to be about.

Code in the module is defining how views will interface with the data in custom table. This includes how we will label the data, any help text, whether we should be able to sort on that field, and what other handlers will be used with that data.

Somebody did ask why we are not creating a content type rather than a custom table. Content types have UIs. Some data does not make sense to bring in as nodes. For example, his company has a custom ticketing system, but it doesn’t have a good reporting system, so the data is exported to Drupal, so views can create better reports; it might not make sense to put that data into nodes.

Once the module tells views about the data in the external tables, the views user interface can start using that data. (Now we’re talking…)

That external data can be used in fields, filters, etc.

Handlers and plugins

Handlers grab data and interpret it. Plugins determine how to output that data.

Views plugins

Display: Tells view “where” to display: Think Views Attach module. Views Attach allows you to display views on nodes and users.
Style: Control view output around rows
Row: Control output within rows

Views results come in rows. If you want to alter the display of the row itself, use the row plugin. If you want to alter the display around the row, use the style plugin.

Structured arrays are used to help create row plugins: structured arrays are used pretty much everywhere in Drupal.

All of this coding gives us the ability to do things with views that it cannot do by default.

My take

This was not what I was expecting when I decided to come to this session. I thought we would be discussing some of the more challenging aspects of building a view, such as arguments and relationships. Instead, we primarily dealt with how to work with views through a module. The information was still useful. I’ve built a plugin for views that allows export of events to iCal formats to add events to Outlook, for example, and this helps me to understand more of what is going on there, beyond how I muddled through that task. I need to learn more about developing for modules, so this helped with that.

It was also eye-opening to see a developer interacting with Drupal primarily through the command line. I use the website, and it’s definitely a different experience.

I am a Mac guy. So I like user interfaces. I like things that help me to more easily do what I want to do: the new user interface for Views in Drupal 7 seems to do a great job of that.