At Commercial Progression, our development team tends not to use bulky modules like Panels or Display Suite without a reason that justifies the overhead. Those decisions (which we revisit frequently) lead to a particular site workflow, which we refine over time.

One Drupal design pattern I used on a recent site led to:

• Entity "view modes" without ds
• Small reusable modules to do Views-like things outside of Views
• Displays of aggregated content controlled through the native UI

It took a bit more work the first time, but I'm excited to use it on the next big project.

Why do this?

Views is full-featured and highly-configurable. You can create views with any number of fields, format each field individually, relate content to other content and then pull the related content in and format fields from that too, filter results based on URL -- all kinds of stuff.

Drupal has a native way to choose which fields to display and format the results, though. And the core Content Type "Manage Display" is easy-to-use and quite extensible. There's an appeal to being able to use "Manage Display" over wrestling with Views.

On the other hand, "Manage Display" does not have all the neat options out of the box. It does simple things quickly and easily. Getting it to do things that Views can do via the UI can often mean writing a custom module to build a new field formatter.

However, you can use rendered entities in Views in multiple ways. If you want a hybrid of Views with fields and rendered entities in custom view modes, you can do that. It remains a flexible way to build sites.

One big appeal of using rendered nodes consistently throughout the site is that you can theme once and ensure a consistent design language is used throughout the site. This requires some forethought when it comes to classes and templating, but is immensely useful when it's all set up.

View modes and templating

Adding view modes in a custom module is super easy:

In the example above, we're defining view modes for nodes (slide, grid), field collection item entities, and profile2 entities. They're all configurable from the core UI.

For theming, template suggestions by display type can be really useful. This example applies only to nodes, but can be adapted for other entity types as well:

That's a drop-in function you can paste and use for allowing template suggestions. Now let's add view-mode-based classes to each rendered node, so we can target it in CSS.

Drop that into template.php of your theme, and every rendered node will come with a useful class for styling.

Let the Field UI do Views-like stuff

If you want your fields to display in basic and default ways, setting up view modes is all you need. But that's not often the case; you end up needing to display a field in a custom way that Views lets you set with checkboxes, dropdowns, tokens, and magic.

To enable this fanciness in the Field UI, you need custom code.

• displaytextformats: pick a particular text format to use for display
• fieldcollectiondelta_display: only show a limited set of field collection items
• fieldcollectionimagelinkparent: Link images in field collections to their host entities

These are examples of functionality I ended up replicating with field formatters that Views just ships with. You'd have to write a lot of modules to get everything, so if you find that more than a few fields need customization, it's probably worthwhile to build a field-based View instead.

Great minds think alike

I found on the Weekly Drop that Jeff Beeman recently posted a blog talking about how to make custom views modes and template suggestions without ds or Entity View Modes module. His post mentions more template suggestions, and is worth a read.