This past week I was lucky enough to take Drupal module development course taught by Gord Christmas. Gord showed the class a lot of really cool stuff, and helped solidify my understanding of some heretofor-considered black Drupal magic (it’s now white magic) - and also demonstrated what rapid prototyping can accomplish in a classroom setting.
But the coolest thing by far that happened was a little aside he travelled down in response to a (slightly snide) comment by yours truly: I said something like “Pshaw. Teasers? Who even uses those things anyway?”
And then Gord said “Well, actually…” And then he totally blew my mind.
I had always thought that teasers were an outmoded display method, a legacy from the old Drupal 5 days. I’d always considered them sort of old-fashioned – nobody ever uses the “river of news” front-page display anymore, and teasers seemed to belong to a quaint era before Views offered its lovely “truncate to X words and add elipses” option.
How wrong I was.
“Only use fields if you have tabular data to display. Otherwise, use Full Node.” The idea here is that you configure teasers in Display settings, and then set up your templates to be aware if it’s a teaser or not, so you can theme it (the full node’s view mode lets you exclude links and whatnot typically shown on full posts, so this might not even be necessary for most things). Then you use Node view in your Views, and what pops out is consistent, every time.
Mind? Blown.
Using teasers for fun and profit
- In any list-type view, instead of adding fields each time you set up a similar view, use Node View and set the Build Mode to teaser.
- Actually configure teasers in your content-type settings – because they’re separately configurable you can show/hide, change display format, and outright exclude totally different things from teasers as from full node. Teaser length is configurable per content-type if you download a little module for 6. It’s rolled into 7.
- Create per-content-type node.tpl.php files. In each templates, test for teaser mode existence and output accordingly (because chances are different types will have different layout needs.)
- In your css, theme *once*, instead of adding CSS classes to your views and tacking on different view-types to .views-row and .views-field-xxx-xxx…
And voila. The payoff is consistent Views displays and no fiddling with fields, consistent single-point-of-configuration, very consistent look across views, much less CSS and easier theming, and a bit of database/caching ease, too.
The trade-off is “extras” – throwing an extra field into a single view will have the same overhead as it did before, you’ll have to add all the fields, and theme for it, etc, etc. But most of the ways we use views is to display lists, and for the most part the only time we change how things look in those lists is for different content-types – and then they appear that way all over the site. We rarely add “just one extra field” unless we’re doing something very View-y like complex relationships using different views-hooked-module-field-output. Because we can still leverage the power of filters, arguments, and relationships, however, those use-cases shrink to something fairly small. And it’s the same amount of work to deal with those anyway.
Now, I haven’t tried this myself. I’m sure as shooting going to try it for the next site I develop. I’ll let you know how it goes – it sounds like a bit more work up front, but thinking about it for half a second reveals that it might actually save tonnes of time, and cut down my swear-words-per-hour rate to something close to manageable.
What are your thoughts? Does this look totally mind-blowing, or more trouble than it’s worth (you know where I stand! =) ?
UPDATE: Was recently reading some performancy-things, and found this entry: avoid calls to node_load. They explicitly recommend using fields in views. Hmm. Mind still blown, but wondering… 
If it’s a small performance trade-off then with caching and whatnot it shouldn’t make a huge difference, but it will depend on the size of the site and your priorities. Benchmark away.
