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:
- 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
- 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
- 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
