[Done] Tables parts 1-5
[Done -- badly] Arguments
[Done] Default Views
[Done -- needs polish] Style plugins
[Done] Other hooks
[TODO] $query object
[TODO] $view object
[TODO] 'multiple' fields
Views is a flexible query builder that will allow your module to expose its data so that Views can build queries with it. While Views has a pretty good idea of how Drupal Core is laid out, you as a developer, must tell Views what to do, or it can't handle your data.
But, if you give Views the proper information, Views can incorporate your module's data and help you build queries.
Views needs to know the following things:
- Each table that contains data that Views might use.
- How this table relates to the Drupal node table, either directly or indirectly.
- What fields users can display in list/table type views.
- What fields users can sort their views on.
- What fields users can filter their views on.
- What arguments users can provide their view to do filtering via the URL and create summary views.
In addition, you can provide style plugins to help control how views that use your module's data are presented, default views so that users can immediately do obvious things with your data without having to build their own views, and several hooks to help you modify a view at various points while it is being built.
How Views works
At its very core, Views uses an object which is a generic query builder. When the $query object is instantiated, it needs to be told what the 'leftmost' table is (for Views this is always node), and when tables are added to the view it needs to know how they are linked to the node table. This helps Views do a lot of setup without the user having to know or care about the exact relationship between a particular piece of data and the core node table.
Armed with this relationship data, when fields are added to a view, either for display, or for sorting or filtering, the query object automatically determines the relationship of that field's table to the node table, and adds the appropriate joins. The core methodology of this system is quite simple:
$query = new _views_query();
$query->add_field($field, $table, $alias);
Obviously, more layers end up adding more complexity; some relationships aren't as simple as others and are more difficult to describe, especially when they are abstract, such as those found in the Content Construction Kit (or flexinode).
What your module needs to do
At a minimum, if your module wants to use Views, it needs to implement one hook:
This function returns data that will describe how your module's tables relate to the Drupal node table, as well as what fields can be displayed and sorted, and how your tables may be filtered. This hook can return just one or many tables.
Additionally, if you want to provide URL arguments, you'll want to implement
hook_views_arguments() to return a similar but smaller chunk of data, and if you want to provide default views that your users can immediately use, implement