This article is intended for PHP developers who are looking at Drupal and Views as a solution for their website projects. If you are a non-technical Drupal Admin, then I have a companion article written for you: “Drupal Views – A Quick Explanation for Non-developers”.
I have to admit that I resisted using Drupal Views for a ridiculous amount of time. After all, I’m a developer with almost two decades of development experience. I can write my own queries. I don’t need all that candy-ass dashboard crap getting in my way!
So, it was with great humility that after working with Drupal for far too long that I finally bit the bullet and sat down to learn Views. If you are still reading this article on the third paragraph, then perhaps you can understand my shame. Both for being too proud to learn such a simple and powerful tool, and also for the fact that I hate to think of all the code duplication I’ve created that was just sitting there already done if only I’d looked at it a little bit longer.
Having gone through my Mea Culpa, perhaps I can save you some pain by convincing you to at least take a hard look at Views before you just jump into the page.tpl.php file and start ripping out queries and functions. Here is what I’ve learned:
Views Are a Powerful Tool - Especially for Developers
If the original intent of Views was to insulate the non-technical Drupal Administrator from all this programming mumbo jumbo (as I suspect it was) then the developers clearly missed their flight. Having spent quite a bit of time now dealing with Views, I can testify that unless a user is a pretty competent developer, they’ll be easily frustrated trying to create Views on their own. The terminology is esoteric and the most common result of blind click-guessing is usually an empty result set.
It really helps to understand how PHP uses SQL and CSS to render websites. While some CMS users might have that type of general understanding, in my experience most don’t.
With proper training, once a View has been created most common updates and modifications should be easy enough for non-technical Admins to achieve with training. My recommendation is that before you hand your projects over to the staff who will administer the Drupal site after deployment you should take time to explain to them that the blocks containing the lists on the page are “Views” and that with few exceptions they should be left alone. It would also be prudent to find out from them whether they expect to change parameters within those lists so you can go ahead and show them a few tricks just so they understand what sort of beast they are dealing with.
So, the bottom line on this is that while non-technical admins could potentially learn to use Views, they are probably more of a development rather than a content management tool.
How Views Are Good For Developers
Views are a bit like having a code library handed to you, and that is the silver lining to all of this because for developers and engineers what Views brings to the table is a powerful method of generating simple queries, arranging the results into HTML structures and outputting the code with CSS classes so that it will look pretty on the page.
Think about how much time you currently spend performing these types of repetitive operations. Views reduces development time and eliminates all the duplicate code that would normally have to be created.
An example of something I recreated without realizing it was with trimming blog post content. I was using queries to pull the last several blog posts from a website and putting them on the homepage. The problem resulted from the fact that the CKEditor was inserting DIVS in the node content as line breaks. When the system was asked to trim the post down for the teaser, it was breaking the DIV structure on the page because the beginning of the text string had the opening DIV tag, but the closing tag was chopped off.
I spent several hours whipping out a system to close open HTML tags in teaser copy, but as it turns out, Views already has this functionality built in (I’m over here chewing on the back of my hand over the time I wasted building a function that I could have accomplished with a simple mouse click).
A short list of several other items we all spend quite a bit of time coding up from scratch, but which are already baked into the Views cake:
- Table column sorting – Yeah, that bit of functionality you have to spend tons of time figuring out how to do without breaking your URLs or writing custom AJAX calls. It’s already built, you just click a checkbox.
- Pagination – I’ve spent far, far too much of my life building, fixing and debugging pagination scripts. Usually this means I only implement them when it’s absolutely necessary. But with Drupal Views it’s literally about four mouse clicks to add it in (even an AJAX version that’s smart enough to deal with multiple pagination objects on one page – wow!). Now I add them for fun and people think I’m extra smart for it.
- Caching – I spent about three weeks building a caching system once, but Views has it built in. You can enable it, disable it, make it time-based, you can cache the query results, or the resulting HTML, or both. Sweet! But can it bring back that three weeks of my life that I wasted?
To be sure there are some things which are just way more complicated than they need to be with Views. For example, sometimes it really is just easier to write a query to pull the information you want.
Another example I can think of immediately is so common that it really begs the question of what they were thinking. Given what Views does, it seems as though you should just be able to click a checkbox to wrap any field with a link to the target node. Unfortunately, you have to pull the link as a separate field and then insert it as a token in a “Rewrite Results” parameter on the target field. This operation is about 5x more complicated than it needs to be.
Drupal Views Help With Security
All that code library stuff is pretty cool, and it would probably be enough to make a believer out of most developers. But there is also another very important benefit to Views: security. As most developers would anonymously admit, sometimes we don’t always write the most secure code. It isn’t that we’re trying to be jerks or don’t want to be secure, it’s just that as we create new functionality we don’t always have time (or the expertise, or simply forget) to lock everything down as tightly as we should.
What Views does in this respect is that it enforces a security regime upon our work and prevents unsecured (read: SQL-injected, XSS’ed, unescaped, or special-chared) queries from being executed against the database since the query process is completely insulated from the site’s code. In short, you have to really try hard to create a security hole when using Views.
I like that.
I could probably go on for another couple thousand words in this article talking about the benefits of Views to developers, but I think I’ve made my point. It isn’t so much that Views will replace the need to write custom queries, but the functionality in Views is deep enough and knocks out enough of the types of functions you are likely to spend heavy hours developing that you owe it to yourself and your development budget to at least become familiar with its capabilities before you spend a significant amount of time developing something that may be just a few mouse-clicks away.
If you want a great set of screencasts on Views, I found this set by a Scandinavian Drupal Trainer that pretty much crushes any questions you have about using Views. It’s mostly addressing the issues that users would have, but obviously as a developer you have to deal with the same questions. So, just ignore the stuff you already know and pay attention because with views there are weird little nuances around every corner – and a few hidden gems as well. Here’s the link.