The bio module does not currently have any views integration. The attached patch (and .inc file in a subsequent comment) add views support that allow the answering of questions like:
- Show me all the blog posts by authors who have tagged their profile with the term "kayaking"
- Find all the bio nodes (whatever the bio type is) by authors who have a first name (where "first name" is a field) like "joe"
- Find all the forum posts by the most popular authors, ranked by most viewed bio pages
Requirements
First, some requirements. This functionality depends on some patches to views. Specifically the following issues:
- view_node.inc handlers not table alias safe
- Provide a handler for IS NULL/IS NOT NULL
- hook_views_tables_alter() cannot add a table
All of the patches are fairly minor and don't change views functionally. The first two fixes could be even be bundled with bio if the patches don't get committed to views immediately. The third is critical for the way bio creates its views table definitions. Please review and comment on these patches. The sooner they can hit, the sooner bio can have some really great views integration.
As a result of needing these patches, bio will require the latest version of views (after the patches are applied) for proper views support. Hopefully this will be views-5.x-1.6
How does it work
Assume we have a "bio" node type, with the following CCK fields: "First name", "Last Name", and "Date of Birth". Let's say we are trying to find all the blog posts by authors with a "bio" node where the "Last Name" field contains "Lincoln." To do this, we must "join" all the blogs against the each one's author's bio node. So the resulting table would look something like:
nid | title | type | last name | first name
1 | Gettysburg | blog | Lincoln | Abe
2 | Emancipation | blog | Lincoln | Abe
3 | At Ford's Tonight | blog | Lincoln | Mary Todd
....
Traditionally, this has been hard because it requires joining one set of nodes to another set of nodes -- not something views supports out of the box. Luckily, we have some useful data to create that join. First, we know the author of blog post will also be the author of the bio node. Moreover, we know that bio nodes are nodes, and that any data that joins to a node generally, could potentially also join to a bio node.
This patch uses hook_views_alter_tables to put both of those ideas to work. First, it takes the "node" table that views provides (with fields, filters, sorts, etc), copies it and makes an "alias" called "bio". It connects "bio" to the real node table by the user id column in both and limits the bio table to only contain bio type nodes. This provides a way to search/display/sort on columns just in the node table (e.g. title, last updated time, node id).
Moreover, in bio_views_alter_tables(), every table that joins against node is copied, aliased as "bio_OLD_TABLE_NAME", and pointed to join against "bio". Thus, CCK fields, taxonomy terms, etc can all be referenced as being part of the author's bio node.
The bio_views_alter_table function also cleans up the resulting tables a little. For example, it does not duplicate the users table, as the author of a "bio" node is the same author as the main node of the query.
Finally, it adds two new filters: "Node: Type is bio node" and "Bio: Author has bio". The first can be used to provide stock views that rely on bio nodes, even though the exact node type can vary from site to site (e.g. on one site it might be "Profile" on another it might be "Contact Me", etc). This is useful for views that return lists of bio nodes directly.
The second limits the view to return on nodes where the author has already created a bio node. This can be useful if you're searching one node type (e.g. blogs) and want to return the "First Name" and "Last Name" fields for every author. This filter will guarantee that a bio node (and its fields) will be present for all blog nodes returned. Useful for table views or other theming.
Between copying any existing views table definitions and providing new filters, some really detailed queries can be constructed.
Reviewing
Get the latest 5.x-dev views and apply the three patches above.
Get this patch and apply to bio.
Start creating views that use bio nodes.
Add your findings to this ticket.
I'd really like to solicit thoughts on the implementation. When this is released, I'm sure people will start building out views based on the functionality. Any implementation changes that we can work out now will probably make their views more reliable going forward, as changes could change the view behavior itself.
Documentation
Notably missing from this patch is user documentation on how to create various bio related views, such as the ones raised at the beginning of this ticket. I think clear user documentation would be key having this functionality adopted.
If anyone wants to start putting together some "cookbooks" for creating bio related views, that would be most welcome. Also, it might be nice to have bio ship with some stock views that show off this functionality. It's much easier to clone and modify a view than to start from scratch. Some good ideas might be a "New Users" style page/block, an updated tracker with the bio node exposed, or a listing of bio field data based on recent posts.
Going forward
I'm also working on some other views extensions to make more "Author's xxxx" fields available. For example, "Author's email". Any other author related data would be really useful in bio related views. Also, if anyone can think of any cool filters or arguments, we could certainly implement those.
Hopefully, this patch gets people thinking about bio+views integration. I think the patch itself is ready to go when the necessary views patches get applied, but of course the more reviews the better.
Cheers,
-Mark
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | bio_views.inc_.txt | 7.93 KB | mfredrickson |
| bio_20070509_add_views_integration.patch | 2.1 KB | mfredrickson |
Comments
Comment #1
mfredrickson commentedAttached the bio_views.inc file. Place it in your bio/ folder and rename it to bio_views.inc
Comment #2
jjeff commentedSchwing!
You, my friend, have just earned yourself CVS access to the Bio project.
Repeat after me, "I promise to use these powers for good and do no evil, etc., etc., etc..."
Commit away, whenever you deem the timing appropriate (what with the Views patches and all).
Comment #3
mfredrickson commentedThanks. As a show of goodwill, I'll make my first commit a bug fix from the queue. :-)
As to this patch, I agree that we should wait for views to accept the patches. I think it would be nice to roll 1.0 release prior to including bio_views.inc -- perhaps with all the current bug fixes in the queue reviewed/committed.
Does this seem a reasonable plan?
Comment #4
jjeff commentedYeah, its definitely about time for a 1.0 release. We should clear out the major issues for the queue and then bake a cake with a big #1 in it.
Comment #5
mfredrickson commentedSince jjeff checked in the outstanding fixes and rolled a 1.0, I've checked in the views patch, along with some small changes, some documentation, and 2 default views to show off the benefit of the new filters and fields.
2 of the views bugs listed above are in RTBC status. The third is an additional function that has been included in bio_views.inc until views proper picks it up, and we can remove if from our own code.
Comment #6
(not verified) commented