Darren Mothersele

Software Developer

Warning: You are viewing old, legacy content. Kept for posterity. Information is out of date. Code samples probably don't work. My opinions have probably changed. Browse at your own risk.

Drupal Views2 Handlers

Sep 9, 2008

web-dev

Views2 is an awesome progression from the original views interface. I've got a feeling the new UI will not please everyone, but I really like the fact it gives a good overview of the current configuration of a view without having to explore lots of collapsible fieldsets.

Views2 is still Release Candidate status, but there's already good support for the new API in other contrib modules such as the excellent Flag module (the progression of views_bookmark). I was forced today to start getting my head around the new Views2 API because I am trying to do something with the BuddyList2 module that requires views - but BuddyList does not yet have Views integration. Here's what I found out...

There's two places to start understanding the Views API. First port of call is the built in Advanced Help which you get when you install the module, and is also available online. Start with the (very brief) description of the API. Once you start to get your head around how the API interacts with the Views system you can start to explore the Views2 API documentation.

My problem here was that I needed to show a list of nodes that had been created by friends of the currently logged in user. To do this I need to make the Views system aware of the Buddylist table by implementing hook_views_data. This is a function that just returns an array of information about the BuddyList database tables. I only need to return some basics here because the only information I'm interested in is that which will help me decide if a node has been authored by one of my 'buddies'.

There's a whole page of documentation on how to implement hook_views_data() but I found looking at some examples examples was essential before I could get my head around what it was doing. Basically you need to return an array. The first element is an array that defines your table info, then you include elements for each field you want to make available. Here's the code that makes the BuddyList relationships available to Views. It's very basic at the moment as it doesn't account for different types of relationship - but let's take a look at how it works...

<?php
function buddylist_api_views_data() {
 
$data = array();

 
$data['buddylist_relations']['table']['group'] = t('Buddylist');

 
$data['buddylist_relations']['requester_id'] = array(
   
'title' => t('Your Buddy'),
   
'help' => t('A link if your buddy did create the node'),
   
'filter' => array(
     
'handler' => 'views_handler_filter_user_current',
    ),
  );

 
$data['buddylist_relations']['table']['join']['node'] = array(
   
'left_field' => 'uid',
   
'field' => 'requestee_id',
  );
  return
$data;
}
?>

As you can see we're creating an array called $data and returning this. In this array we put information about our database tables. In order to find the nodes created by the people I befriended I need to join the node table to the buddylist_relations table based on the requestee_id. The requestee_id contains the uid (user id) of people on the receiving end of a friend request. You can see this join happening in the second half of the code.

The first half of the code exposes another of the Buddylist database columns as a filter. It uses the requester_id which is the uid (user id) of the person initiating the friend request. This is passed to one of the pre-existing handlers - so we don't have to write any more code! The views_handler_filter_user_current handler exists within the views user.module handlers. This takes the database field and will filter out the records that match the current logged in user.

I think the next step is to considering the effect of different user relationships defined in the BuddyList module, and how a custom handler would be built to accommodate this.