Should we be making the effort to expose our custom modules' fields to Views,

Definitely. Your users will want this.

and then generate lists we want with the Views module?

This is of course optional, but has many advantages. One is ease for you as a developer. Yes, you know how to generate these lists manually. Still, it's coding time to generate them and then modify them when a changed UI is wanted. Assuming you've already taken to the time to expost your data to Views, the task now becomes easy. You build your views to spec, export them, copy the code, and put it into a hook_views_default_views() implementation. Want some change to the presentation? Change your view, then re-export. Key advantages as I see them are: 1. Reduced code that you need to maintain. A default view isn't really code you're stuck maintaining--it's something you can configure and reconfigure through a UI. 2. Flexibility for your users. Seldom will you be able to hard-code a data presentation that's exactly what all your users want or need. By providing a default view, you give your users your best guess, but leave them full control over customizing to their own needs. 3. Examples to work from. Depending on the complexity of your module and its data presentation, it may be difficult for some admins to figure out how to construct effective views of your data. This is especially true if you e.g. expose argument fields or have complex filtering possibilities. Besides accomplishing their direct aims, default views also provide useful tutorials for admins wishing to take advantage of your views implementations.

"Ryan Courtnage ��& " <ryan@courtnage.ca> writes:

Now we are at the point where we need to start presenting lists of our custom content in various forms. Teaser lists, title-only lists in blocks, among others. For creating these lists, we have 2 options: direct use of db_query or use the Views module.

I think Views is great and, depending on your requirements, can provide enormous added value. For example, a client site that just launched has a very nice search and index page (http://7dvt.com/searchindex) built entirely around a single View in one day. That said, Views is not always the best choice. If you have a complex custom query that is not going into a contributed module (ie: it's something custom to the site), it will be simpler to write it directly than to indirect through Views. It will also be more efficient. From a site/code maintenance point of view, it is much nicer to have a query under version control than a View defined in your database. Sure, you can export the view and check that it but the results are larger, harder to read and edit, and just not as natural. In my experience, clients/site admins do not use the powerful Views UI to build or edit their own views, even though they can. They have the site designer or coder do that and the Views only change during major site upgrades. So the query-building UI ends up just being a longer, more labor-intensive way of writing "SELECT ...". The big payoff of Views, in my opinion, is not the query builder. It's Arguments (especially in Summary or Show All mode), Exposed Filters, and Style plugins (e.g. List, Table, Calendar, etc.). If you need Arguments or Exposed Filters, using Views will save you time. If you just want to use a style plugin... well, I lobbied Earl to separate Views into two modules, Query and "List Display" or something, so you could construct a custom query but still use the Calendar display plugin, etc. He didn't do that but says that Views 2 will allow something similar. Hope this helps, Barry