Using Views Relationships, Arguments, and Attachments

This article is also available in French from KolossalDrupal.

There's an incredible amount of functionality that can be provided by the Views module, especially when it is combined with intelligent use of Node Reference fields. When you relate your site's nodes with Node Reference fields, these relationships can be easily leveraged to create some very useful views.

I'm going to build a view for a sample music site. In the site, I have 3 related content types for "Band" nodes ("Black Eyed Peas", "Linkin Park", etc...), "Album" nodes ("Back in Black", "Bat Out of Hell", etc...), and "Events" (concerts, television appearances, etc...)

Each of these content types has only the minimum fields to demonstrate the Views functionality that is the subject of this article. For example, the "Event" content type doesn't have any location or date fields - they can be easily added at a later time.

To associate the 3 content types, both the "Album" and "Event" content types have a Node Reference field that allow their nodes to point back to a "Band" node. For example, when a new "Album" node is created, the user is forced to select the appropriate "Band".

In order to make use of these content types, I went ahead and populated several nodes of each type so I have some data to work with when creating the view.

The goal of this article is to be able to create a page that displays a single band node along with all of its albums and events. Here's a quick sample of what I'm aiming for:


Band Info
[Band Name]

Albums
[Album 1]
[Album 2]
[Album 3]

Events
[Event 1]
[Event 2]
[Event 3]

There are several ways to accomplish this - Panels (context) and blocks (visibility) come to mind - but I'm going to use a method that utilizes only Views Attachments. Regardless of the method choosen, it's almost guaranteed that you'd have to create some views so why both with the extra overhead of additional modules and/or code?

A Views Attachment is simply a type of Views Display that gets attached to another View Display (usually a page display or a block display). Simplifying things, it can be thought of like this:

The diagram shows that Page and Block displays (as well as other types of displays defined by other modules) can have any number of attachment displays. These attachment displays can physically appear on the page either before or after the display it is attached to.

For this example, I'm going to create a view that has one Page Display (called "Band Page") and two Attachment Displays (called "Albums Attachment" and "Events Attachments"). The two Attachment Displays will be attached to the bottom of the "Band Page" so we end up with the desired outcome as outlined above.

As usual, you can download all the CCK types and view exports at the end of this article.

For the first step in creating the view, I went to the admin/build/views/add page and created a new node-based View called "band_info" with the following values on the "Defaults" display:

Basic Settings

Title: Band Info

Arguments

Node: Nid ("Action to take if argument is not present: Hide view / Page not found (404)")

Fields

Node: Title

Filter

Published: Yes

Type: Band

Next, I created a new "Page" display and named it "Band Page" and set its path to: "band/%". Remember, the "%" is just a placeholder for the "Node: Nid" argument I set up in the "Defaults" display.

At this point you can save the view and check it out in the "Preview" pane by entering in a valid Node ID for a "Band" node in the argument field. The view should show only the band's name that is associated with the Node ID you provided as the argument.

Now for the interesting stuff. I'm going to create an Attachment display that shows all of the Album nodes for the Band specified by the Node ID in the argument. Remember, there's nothing all that special about Attachment displays. They're just like any other Views Displays except that you can attach them to other displays. To create the "Albums Attachment", I started by selecting "Attachment" from the display select box and clicking the "Add display" button.

Initial setup for the new display is straight-forward:

Basic settings

Name: Albums Attachment

Attachment settings

Position: After

Attach to: Band Page

Since this display is going to show a list of "Album" nodes, I want to set the "Node: Type" to "Album". When doing this, I have to be careful not to change the default settings for the entire View - I want to change the settings just for this attachment. To do so, I click to edit the "Node: Type" in the "Filters" section, then click the "Override" button so that I'm only modifying the current display and not the entire view:

Once the setting is overridden, I can then safely change it to "Album" without worrying that I'm messing up the other displays. It is easy to tell when a setting is overridden: it is no longer displayed in italics in the display summary:

Here comes the tricky part: now that our display is going to show only Album nodes, how do you filter it by the Band's Node ID? With a "Relationship", of course! Remember, the Band and Album content type are related via a Node Reference field. We can utilize that relationship to filter the Album nodes. The first step is to add a new relationship to the "Albums Attachment". In this case, I'm going to add a "Content: Band" relationship. Before I do this, however, I have to ensure that I'm adding this relationship only to the Albums Attachment, not the entire view. This is a common source for mistakes. Take note of the "Relationships" section - notice how it is italicized? That means anything I add to it is actually getting added to the Defaults display - and all of the displays that inherit from it. I first need to click on the "Relationships" link and click the "Override" button.

Once this is done, I know that I'm safely adding the relationship to only the "Albums Attachment" display. I'm going to add the relationship that links an "Album" node to a "Band" node - in this case, that is the "Content: Band" Node Reference field.

After adding the relationship, I'm presented with a couple of settings. The "Label" is used only to help identify the relationship as it appears in this particular view. When adding multiple relationships to a view, it is helpful to give them meaningful names. Luckily, Views does a pretty good job at assigning the default, so I'll stick with that.

In this case, the "Require this relationship" option is not necessary because I know that the argument will filter out all but those Album nodes I want to see.

The final piece of the puzzle has to do with the "Node: Nid" argument. Since the "Albums Attachment" display is inheriting the argument from the "Band Page" display, I have to make sure that it is using it correctly. As it stands now, the display will try to filter the list of Albums with the incoming Node ID argument. This won't do much of anything since the incoming argument is the Node ID of a Band. I need to tell the view to use the argument to filter the Album nodes returned by the Band - using the Relationship I just set up. Turns out this is pretty easy to do.

First off, I need to click to edit the "Node: Nid" argument and then click the "Override" button so that my changes only affect this display. Then, I need to set the "Relationship" select box to "Band". This will effectively filter the Album nodes returned by their associated Band node's ID.

One final thing I did to the attachment to make it a little more user friendly was to override the "Header" setting and add the following:


Albums


This will simply display a nice header above the albums. Taking a quick look at the Preview pane with the appropriate Node ID for a Band, you'll see something like this:

At this point, the "Albums Attachment" is just about done. You can add some additional fields, sorts, and display options, but the challenging part is complete.

The "Events Attachment" works exactly the same way. The main difference is that the "Node: Type" filter uses the "Event" content type, but everything else is analagous to the "Albums Attachment" display.

Putting everything together, the final view looks like this:

It's not too hard to imagine how you can utilize these tools to generate all sorts of interesting views of this same data. Perhaps an Album or an Event page that shows information from the associated Band node. Maybe add a new content type for "event location", then you can build a view that displays all events by location along with Band information for each event. The method outlined here is flexible enough to allow you to drill as far down into your data as you need.