Creating a views handler for Drupal 6 - Part I

A note about the purpose of this post:

I tend to work from the UI backward when I can.  It's helpful to mock up the process little by little, and working front-to-back lets you click and experience the work you're doing early on.  That can have good results with usability, and also can help to clarify thinking when you don't know quite what you're building yet. 

In the case of both views and custom CCK fields, I've had difficulty figuring out how to achieve that basic prototyping, as their methods of implementing the UI layer are very specific and abstracted.  Even after reading several blog posts and the views API documentation, the process of creating a filter for views was still fairly opaque to me.  Sometimes the minimum set of steps to achieve a simple result isn't top-of-mind when people blog about development tasks, so I'm making my own notes.

In Drupal, the all-important Views module can be extended with 'handlers'.  Handlers are used to implement filters, fields, and arguments.  They are php classes, typically contained in a .inc file somewhere in your module directory.  You describe your classes and how they'll be used by implementing one of several hooks.  The most lightweight views filter implementation requires 4 things: 3 hook implementations and a class. 

Hooks you must implement:

1. hook_views_api - this declares that you're going to do something 'viewish' with your custom module.  This function returns an array specifying the lowest views api version you'll support, and where your module is located.  See http://views.doc.logrus.com/group__views__hooks.html#gc67ffd4a2f61f9814ee37b541c472c47hook_views_data
2. hook_views_handlers - here you announce to Drupal that you're implementing an handler.  This hook specifies you'll specify the parent class and the filename your class lives in.  See http://views.doc.logrus.com/group__views__hooks.html#gbf506f44bd8d8a86876f27396f5341ed
3. hook_views_data_alter OR hook_views_data - these hooks tell Views where your handler fits into the data model that views uses to generate queries.  For simple filters that rely on existing tables, use hook_views_data_alter to add your handler to, say, the information already related to the node module.  If you've got a whole module with its own tables, you'll want to describe them to views using hook_views_data.  The array that describes your data to views does so field by field, specifying what kind of field, argument and filter handlers your fields will use.  You'll also be able to specify relationships and joins to other data in hook_views_data.  See http://views.doc.logrus.com/group__views__hooks.html#g227057901681e4a33e33c199c7a8c989

Once you've told Drupal your module wants to work with Views (hook_views_api), that it implements handlers (hook_views_handlers) and how the handlers relate to the database schema that Views knows about, you're all set.

Well not really - with the three hooks implemented, and your cache cleared to pick up the new hook implementations, you'll be able to see your handler in the appropriate spot in the views interface.  In my case that was in the taxonomy group under 'Filters', as I was implementing a slightly customized term id filter.

With the hooks, you'll be able to select the filter and add it to your view - but the filter class doesn't exist yet.  Views will tell you that your handler is broken, but you will be able to see the handler in the Views UI.

Next you have to implement the class - I'll make more notes about that later...

Posted via email from dsayswhat's posterous