I am working on a project that involves storing/cataloging lots of links. The people in charge of gathering information and storing/updating links will also be checking for and fixing broken links. They won't necessarily be tech-y people, though, and so I wanted to be able to customize the Broken Links report so that I could show only certain errors/response codes, or even translate some of it into English (maybe show the word "Redirect" instead of "301," for example). I also thought it would be useful to filter the report to only show certain content types, in case someone is only in charge of administering links within a certain content type but not another. And if I go this route, I thought it would be nice to be able to create multiple, different Broken Links reports, each of which shows different types of information.
To make it easier to do all the customization I wanted, I wrote a simple module that integrates the Linkchecker tables with Views via hook_views_data and then provides a default view set up to look exactly like the Broken Links report, via hook_views_default_views. Since these hooks are contained in one file, the only action that would be needed to include Views integration in the module would be to include linkchecker.views.inc (which I've attached to this post - you'll need to rename it to linkchecker.views.inc) in the module directory, and then add hook_views_api to the .module file as follows:
'api' => 2.0,
I don't know if my needs were so specific that no one else will find this useful -- in which case I'll just keep this code in my own custom module -- or if anyone thinks this would be a good idea to include in the linkchecker module by default. Also, I'm sorry for not writing a patch - I don't really know anything about how to go about that, or how CVS works, or anything, and I figured that, since 99% of this code is in its own, separate file, that it wouldn't really be worth it to write a patch that just implements hook_views_api.
Anyway - let me know what you think. Thanks!