Getting the most out of Views 2.0Jay Callicott

September 19, 2009

Drupal Camp Atlanta

Introduction: Session Outline

Introduction to Views 2.0

Why views?– Advantages of using views over database queries

Db query vs Views side by side comparison

Theme-centric vs Logic-centric approaches to view creation

A case study on 2 main strategies for creating views

Views 2.0 Wrap Up & Q&A

Introduction: Informal Poll

How many beginner Drupal developers?– Advanced?– How many non-developers?

How many here came to the conference for kicking the tires of Drupal?– Training?

Introduction: Intended Audience

Beginner to advanced developers– The material is more advanced but I will try to not lose

beginners

Business Guys (Managers/Owners/CIOs) wanting to learn the power of Drupal

Introduction: Who Am I?

Jay Callicott– Mediacurrent web developer– Drupal developer since 4.6– Started using Drupal in a part-time business I started several

years ago– Developed web applications for the state of Arkansas before

this job– Expert in PHP/mySQL and Drupal as well

• worked with Drupal versions: 4.6 / 4.7 / 5 / now 6

Introduction: What are views?

Views are a critical feature of Drupal– As big as CCK, robust theming layer, modular framework– *Will be rolled into Drupal 7.0 core

• *Edit, this is not correct – I think I got confused with CCK?

Views are for building arbitrary lists of content.– Not unlike “lists” in Sharepoint, other CMS’s might have similar

concepts

Views can be blocks, pages, embedded

Views can pull any type of Drupal content (nodes/users/etc) and do some amazing things all from the UI!

Introduction: Why did I create this session?

This session is more me 1 year ago.

Intended for someone who has used Drupal, even beginner-level who is trying to get a grasp of Views 2.0

Or for Drupal 5 developers getting a handle on the transition of Views 1.0 to 2.0

Views 2.0 can look intimidating at first

Why views? Advantages of using views over database queries

The usual alternative to views is the quick db query– Fetch results in module, spit out html– Absolute control!– Tempting if you are used to custom coding

Fine for quick? Or is it?– As requirements grow, code grows and maintenance

becomes a problem

Views can do simple and can grow as requirements grow– Views are extremely flexible and scalable

Views vs db_query comparison chart

Views Db query or custom code

Some limitations – see next column, but plenty powerful

Total control – data can come from anywhere: XML, multiple databases, remote sources, etc.

UI import/export a little more trouble Easy to deploy across environments

Look ma – no code! You can create robust views with Views UI

Prone to errors – SQL errors (pain), code errors, logic errors

No modules to mess with! More overhead – create module, enable it, create info file, find Drupal hooks, more work.

More Views vs db_query comparison chart

Views Db query or custom code

Less time, less headache – Just pick and choose the content/fields and filters you want

More time – e.g. with CCK content it’s take a while to find all the db tables you need to join

Beginner developer/themer friendly More technical – need to know PHP/mySQL well

Caching automatically Caching must be turned on with cache_get/cache_set

Power built-in: Permissions / page url / caching / sorting / filtering / ajax / styling even – views 2.0 has kitchen sink thrown in

Maintenance & scalability a problem – adding sorting/filtering/pagination quickly expands the code

Db query vs Views – side by side comparison

We will go screen by screen

First create a module using custom db query

Second create a view that does the same thing

Enabling the module…

Enabling the block…

Viola! Recent Stories Block v1

Recent Stories Block v2

Let’s Add a Subtitle! (Using CCK)

Need phpMyAdmin to analyze CCK

My first attempt = MySQL error

Recent Stories Block v3 – We’re done!

First screen

Add a filter…

Add a filter step 2

Add a limit (3)

Add a sort…

Add a sort step 2

Add style…

Add subtitle…

Add subtitle step 2

Add title link…

Add title link step 2

We’re done! Time to save.

Live preview!

Enable the recent stories block…

We’re done!

Theme-centric vs logic-centric approach to view creation

Methodology is critical– Especially with large projects

Views 2.0 methodology approaches: look & feel or logic– Documentation covers nuts & bolts, not strategy

Views 1.0 didn’t have this problem– Each list was usually it’s own view– With 2.0 you can combine lists together

Theme-centric – aka look & feel

Simple list– Add displays for recent articles,

recommended articles, popular, gear items, species

– All displays get rolled up into 1 view

Image list– Image on left– Title, additional fields on the right

Featured item– 1 content item from a content type,

big image, more fields, etc.

Logic-centric methodology

Recent articles– Add displays for species articles,

gear articles / add displays for blocks / pages

Most popular– Add displays for species / gear /

hunting / etc

Related articles– Gear, hunting articles that have a

certain taxonomy term passed in through an argument

– E.g. you pass in ‘deer’, ‘fish’, whatever and get articles that have that term

Comparing the 2 approaches

Both approaches sound reasonable

My experience building around look & feel is much more maintainable and is more sustainable

Logic approach can lead to much frustration

Comparing Approaches: L&F

Sharing templates is easier

Look is the same/similar you should share CSS

Won’t have to branch off .tpl templates for different content

Comparing Approaches: Logic

Maybe share templates

What if the logic is similar but the look is different?

Some displays might be pages, some blocks

You could be forced to create a bunch of templates

Template explosion can occur!

More on Logic regarding templates and CSS

You have a recent articles block and a popular articles block across 2 views.– Both have same look = similar .tpls and duplicated efforts

Bloated CSS– Views have different ids/classes (will show example later)

Template Duplication– Similar templates are created– Template customization gets duplicated– Maintenance becomes a nightmare

Comparing Approaches: L&F v. Logic

Look & Feel

You will override fields and some filters

All the styles will be the same = consistency

Logic

You often override more here than in look & feel approach

Maybe styles and filters and fields

Views become very hard to maintain!

A Case Study on 2 Approaches

Guns admin view list…

Guns short teaser admin edit…

Guns short teaser admin edit #2…

Gun short teaser image CSS…

Petersen’s Hunting…

Hunting view admin screen…

Hunting Recommended Article CSS…

Wrap-up

Covered basics of views, in detail why we should use them over custom code

Showed side-by-side how creating a view over code is often preferred

Covered 2 main approaches or strategies when creating views and the implications of these 2 main approaches

Displayed a real-world scenario and explained implications for each strategy

Q&A

Can views do ‘X/Y/Z’?

Your specific business problem, can views help?

General questions about Drupal? Mediacurrent?

Got more questions later?– Jay.callicott@mediacurrent.com– or twitter http://twitter.com/drupalninja

Thanks for coming!