Rules Bonus Pack: Views

Screencast can be downloaded from archive.org or Vimeo. Creative commons, as always.

Today I wrapped up another of my crazy Rules ideas – for some time I have been thinking about letting Rules react on Views events, and also altering views as they are being built. There is now proof-of-concept functionality available in the [Rules Bonus Pack project](http://drupal.org/project/rb), and eventually I hope that this will be a part of Views Bulk Operations (since that module currently has the most extensive Rules/Views integration).

So, what's new?

* There are three new Rules events available, corresponding to the pre_build, pre_render and post_render events in the Views process. Rules can hook into these and make changes to the view, or perform other actions based on the view data.
* There is a new data type available for Rules – a view display. (Actually it is a light-weight representation of a view, since view objects tend to get pretty heavy.)
* The new view data type exposes some read-only properties to Rules: machine name, human name, display (machine) name, base table, total number of rows (assuming the view has been built) and also view output (assuming the view has been rendered). These can be used in conditions and actions, just like any other data.
* There are also some writable properties that Rules can change: contextual filter values, current page number, items per page and offset.
* The view also provides its handlers, but this currently only supports reading alias names and the action 'unset a view handler'. The latter one can, for example, be used to remove a selected field or filter when certain conditions are met.

So, what can I do with this?

This functionality is still very much being explored, so expect new things to appear (and also expect a bug or two). However, there are some cool things you should be able to do with this:

* If a view has 10–20 results, show them all on one page (instead of getting a relly short pager).
* If there are no results, redirect the user somewhere else and show a message.
* Set contextual filter values in more complex ways than Views can manage itself.
* Remove certain filters if the acting user is administrator.
* Change certain contextual value filters if the acting user is administrator.
* If you're not on the first page of view results, remove the offset.
* Combine with Rules Bonus: Theme to set the view title to "Found 23 hits when searching for 'pancakes'".
* More things that you're better at finding than I am.

Note: If you want to affect things like items per page or contextual filter values, make sure to to it on pre_build. Just saying.

So, what's the point?

There are two points with this. The first one is that there is now a data bridge between Views and Rules. These are two of the most flexible and powerful modules in the Drupal eco system, and I think this will be extremely useful (especially when the functionality gets adopted by someone who knows Views coding better than me).

The other point is to show off how much fun you can do with Rules, with a pretty small effort. If you have a case of "if this then that", then Rules is a good bet for your solution. If you build a "Views Conditions" module to do tweaks and alters to your views, you can probably solve the specific problems you have. But building this functionality with Rules means that there are *loads* of other use cases, most of which you haven't thought of.