Update: Please see the code at https://gist.github.com/1460818 for a working example with the current bean code base.

In my previous post I talked about how we decided to leverage EntityFieldQUery as an alternative to Views for aggregating lists of content. In this post we'll be looking at how Treehouse created the Bean module to create and place blocks containing these lists of content.

If you are like me, you have avoided diving into coding for the black hole that is Views. Every time I started to look at the mass amount of documentation, I went blind. There is no shortage of documentation and examples. Besides looking for how other modules have implemented Views, the following documentation is available.

This is the last post in a 4 part series about Views, Views Bulk Operations, Actions and Features. In the first post of the series I walked through the Views Bulk Operations module. In the second post, a high level plan was put into place for the comment moderation feature. We also created the action plan that we followed for the final two posts. In the third post, we implemented several parts of our action plan. This included the view, creating the feature and coding the actions.

This post will finish up the comment moderation feature. Below is the action list. The bold items are addressed in this post.

Create View with 2 page panes.

A client recently had a requirement for what we call a canned search.  A canned search is simply a saved search with specific criteria that can be accessed directly at a URL.  This allows content editors to easily generate a list of various types of content suited to a specific topic without having to specifically link the items together in another manner.

In my last post, I walked through the high level plan for the Comment Moderation feature. We came up with a summary of tasks. In this post we will be creating the views and actions. Below is the list of the tasks, bolded tasks are being tackled today.
Create View with 2 page panes.

In the last post, I walked through the Views Bulk Operations module.  My initial plan was to write this post about actions, but  after researching how to best write about actions, I found a ton of detailed information about how to make an action. 

Did you ever find a Drupal feature that was so incredibly simple and easy to use that you were sure that everyone else already knew about it? Using Views Bulk Operations (VBO) together with Actions was one of the moments for me. Asking around to my fellow developers, I discovered that the use of the combination of VBO and Actions is common. In this blog series, I am going to walk you through using VBO and Actions to create some kick-ass administration forms.

In a previous article I extolled the virtues of keeping your Views in code, which lets you deploy or change them as easily as uploading or updating a module on your production site. In the article, I wrote about using Drupal 6 and Views2 to do so.

Drupal 5 / Views 1 Execution

Views 1 for Drupal 5 also has this mechanism in place, so if you're working on a Drupal 5 site, it's still worth using. It’s how the calendar and date modules provide a default calendar view, among other things. The method for putting default views in your modules is pretty similar, and it’s still a great technique to practice. In Views 2 for Drupal 6, you had to implement two hooks to have a module provide default views in code: hook_views_api() and hook_views_default_views().

Since getting started with Drupal over two years ago, the sites I’ve built with it have naturally gotten bigger and bigger in scope. As your sites get bigger and bigger, you always look for ways to keep your site running as smoothly as possible, and this usually ends up meaning getting rid of queries wherever you can.

One feature of Views which is often used by module developers is the ability of a module to expose a set of default views. The calendar module, for example, provides a default calendar view in both its Drupal 5 and 6 versions. This is an obvious asset for developers of contributed modules: if your module interfaces with Views, it makes sense to provide a default view that users can modify.

Implementation and Potential Benefits

The hook used to do this is hook_views_default_views(). Since most modern sites are run off of a number of Views, you can also realize several benefits by building your sites with a custom module that implements hook_views_default_views():

1. It improves performance. Views implemented via hook_views_default_views() do not require a database query to instantiate. You will realize an even greater performance gain if you also use an opcode caching system such as APC or XCache.
2. Providing views in code will allow you to override the default view to make changes, and you can then choose to keep the changes in the database, update the module file to reflect the changes, or revert back to the version in your module file.
3. Because the view (and theoretically, changes to that view) are stored in files, you can put them in version control and see how the views used in your site change over time and revert to an earlier version without having to go to a database backup.