Views Developers

Starting Views2 Documentation

drewish — Tue, 25 Mar 2008 22:30:23 +0000

Creating this wiki page as a dumping ground for bits of documentation on Views2. It's totally a work in progress that can serve as a basis for future handbook pages.

Hooks

Merlin keeps changing the signatures so go check the code to see how they're really supposed to be used, this should just give you an idea what's out there.

hook_views_data: Tells views about the tables, field, filters, arguments, etc.
hook_views_default_views: Lets modules provide default views.
hook_views_convert: Converting views1 views to views2.
hook_views_query_substitutions: Query substitutions

Terminology

Pseudo Table: A pseudo table is not much more than defining the name of the table as a table that doesn't exist. For example, $data['term_data_' . $vid] = array(...); Then, in that data, you need to tell it that 'table' => 'term_data' so that it knows it's the real table. And in the 'extra' part of the join, you generally do something like 'vid' => $vid
If you've got a SQL background you may know this as an aliased table that's added to the query as part of a complex join e.g.:
LEFT JOIN {term_data} term_data_1 WHERE term_data_1.tid = term_node_1.tid AND term_data_1.vid = 1

Easy embed

Note that this function passes any additional parameters to the View as Arguments.

/**
 * Embed a view using a PHP snippet.
 *
 * This function is meant to be called from PHP snippets, should one wish to
 * embed a view in a node or something. It's meant to provide the simplest
 * solution and doesn't really offer a lot of options, but breaking the function
 * apart is pretty easy, and this provides a worthwhile guide to doing so.
 *
 * @param $name
 *   The name of the view to embed.
 * @param $display_id
 *   The display id to embed. If unsure, use 'default', as it will always be
 *   valid. But things like 'page' or 'block' should work here.
 * @param ...
 *   Any additional parameters will be passed as arguments.
 */
function views_embed_view($name, $display_id = 'default') {

API

Earl's been using Doxygen to generate API documentation: http://views2.logrus.com/doc/html/index.html

Load a view:

<?php
$view = views_get_view('view_name');
?>

Initalize it and add arguments:

<?php
$view->set_display('page');
$view->set_arguments(array('first', 'second'));
$view->is_cacheable = FALSE;
?>

Or add a filter. Works for fields, sorts, and arguments as well.

<?php
$display_id = 'default';
$view->set_display($display_id);
$id = $view->add_item($display_id, 'filter', 'og_uid', 'is_admin');
$item = $view->get_item($display_id, 'filter', $id);
$item['value'] = array(0, 1);
$view->set_item($display_id, 'filter', $name, $item);
$view->is_cacheable = FALSE;
?>

Get an array of the view result objects:

<?php
$view->execute();
foreach ($view->result as $result) {
  foreach ($view->field as $id => $field) {
      if (!empty($view->field[$id]['handler'])) {
        $view->field[$id]['handler']->pre_render($view->result);
        // Do something with this unrendered result object
      }
    }
 }
?>

Another way to get array of results:

<?php
$view->render();
foreach ($view->result as $result) {
  // Do something with this rendered result object
}
?>

Use a custom display plugin

<?php
$display_id = $view->add_display('my plugin');
$result = $view->render($display_id);
?>

Another method

<?php
$view = views_get_view('my_view');
$view->execute_display($display_id, $args);
?>

Writing Views 2 style and row plugins

The Views 2 API has changed significantly from Views 1: it has been reorganized and is now much more object-oriented, but the basic concepts remain the same. You use the Views UI as a dynamic query builder to construct lists of nodes based on fields, arguments, filters, and sort criteria, which can then be styled and displayed in quite a number of ways. You use style plugins to display nodes in any type of format from simple HTML tables to more exotic formats based on XML and JSON. In this tutorial I'll go over the steps I took to create a new Views 2 style plugin for rendering nodes in the JSON data format and a Views 2 row plugin used by my style plugin .

New Views styles for displaying nodes in the JSON data format

A complete style plugin is made up of these four components:

An implementation of hook_views_plugins to declare your style plugin;
An implementation of the views_plugin_style class;
A theme preprocess function for your style theme;
A theme .tpl.php page.

0)Organizing the module files. Views 2 automatically looks for plugins supplied by modules in files named module_name..views.inc. They can be in the module directory or an 'includes' sub-directory. My module will be called views_json so in my views_json folder I have a views_json.views.inc code file. json_views.module is empty but could contain unit tests for the plugin.

1)Declaring the plugins
Whereas in Views 1.x you declared your style plugins by implementing hook_views_style_plugins, all Views 2 plugins are declared by implementing hook_views_plugin and indicating the plugin type as the name of the top-level array containing your plugin definition:

<?php
/**
 * Implementation of hook_views_plugin
 *
 *
 */
function views_json_views_plugins() {
  return array(
    'style' => array( //declare the views_json style plugin
      'views_json' => array(
        'title' => t('JSON data document'),
        'theme' => 'views_view_json',
        'help' => t('Displays nodes in the JSON data format.'),
        'handler' => 'views_plugin_style_json',
        'uses row plugin' => TRUE,
        'uses fields' => TRUE,
        'uses options' => TRUE,
        'type' => 'normal',       
      ),
    ),
    'row' => array( //declare the unformatted row plugin
      'unformatted' => array(
        'title' => t('Unformatted'),
        'help' => t('(Displays the unformatted data for each row from the views query with each row on a new line. Set as | for views_json.'),
        'handler' => 'views_plugin_row_unformatted',
        'theme' => 'views_view_row_unformatted',
        'uses fields' => TRUE,
        'uses options' => TRUE,
        'type' => 'normal',
      )
     )  
  );
}
?>

In this case I'm declaring a style plugin called views_json and a row plugin called unformatted. I need the row plugin because I want to get at the unformatted text for each record returned from the views query, and the default row plugin adds a lot of html formatting that I don't want.

2)Implementing views_plugin_style and views_plugin_row. One cool thing about Views 2 is that every default display type, style, and row are implemented as plugins derived from base classes from the root superclass views_plugin So I could just look at the code written for the default plugins to have a really good guide on how to implement my own.

I created a class views_plugin_style_json (inside views_json.views.inc) deriving from views_plugin_style:

<?php
/**
 * Implementation of views_plugin_style
 *
 */
class views_plugin_style_json extends views_plugin_style {
  
  /**
   * Set default options
   */
  function options(&$options) {
    $options['format'] = 'Exhibit';
  }
  
  /**
   * Provide a form for setting options.
   *
   * @param array $form
   * @param array $form_state
   */  
  function options_form(&$form, &$form_state) {
    $form['format'] = array(
      '#type' => 'radios',
      '#title' => t('JSON data format'),
      '#options' => array('Exhibit' => t('MIT Simile/Exhibit'), 'Canonical' => t('Canonical'), 'JSONP' => t('JSONP')),
      '#default_value' => $this->options['format'],
    );
  }

} ?>

If you're curious about the base views_plugin_style class and all the members our class inherits, you can view the source here. Most of the boilerplate code for setting up a views style plugin is done already in the base class, I just need to implement my custom bits (+1 for OO). My implementation does only one custom thing - provide a form for users to select the JSON format they want to render. This is done by implementing options_form.
Form building for options form is similar to building forms through the Form API. An options form can be very simple, like ours which is just presenting a single set of radio buttons, to a very complex one like the one the table style uses:

Table style options form

In the next iteration of our JSON plugin we'll use a more advanced options form to allow the user to select what fields to render and maybe use different labels for field.

For our row plugin we follow the same pattern: we extend views_plugin_row inside views_json.inc:

<?php
/**
 * Implementation of views_row_plugin
 *
 */
class views_plugin_row_unformatted extends views_plugin_row {
    
    /**
     * Set default options
     *
     * @param array $options
     */
  function options(&$options) {
    $options['separator'] = '|';
  }

/** * Provide a form for setting options. */ function options_form(&$form, &$form_state) { $fields = $this->display->handler->get_option('fields'); $options = array(); foreach ($fields as $field => $info) { $handler = views_get_handler($info['table'], $info['field'], 'field'); if ($handler) { $options[$field] = $handler->ui_name(); } } $form['separator'] = array( '#title' => t('Separator'), '#type' => 'textfield', '#size' => 10, '#default_value' => isset($this->options['separator']) ? $this->options['separator'] : ',', '#description' => t('The separator is placed between fields.'), ); } } ?>

In this case we also have an options form which is displayed to the user for selecting a field delimiter.

You'll notice that we have reference to 'handlers' in each bit of code Each view has handlers designed to respond to certain actions. @TODO: explain handlers (not needed for the rest of the tutorial)

Once we have our options form setup we can process to the heart of the style plugin - the theme template preprocess function and most importantly, the theme template.

3) (optional) Implement template_preprocess_
Inside template_preprocess_ you setup variables to be accessed by the plugin theme template .tpl.php file.You can also modify variables before they are passed to the theme template. You can read more about template_preprocess functions here:http://drupal.org/node/223430 as they are part if the standard Drupal theme system. In the class we extended - views_plugin_style - there is this method defined:

<?php
function render() {
     if (empty($this->row_plugin)) {
       vpr('views_plugin_style_default: Missing row plugin');
       return;
     }
     $rows = array();
     foreach ($this->view->result as $row) {
       $rows[] = $this->row_plugin->render($row);
     }
     return theme($this->theme_functions(), $this->view, $this->options, $rows);
   }
?>

theme_functions() returns a full list of possible theme templates used by this style. render() is what is called by the view's display for the style plugin to do it's thing. In addition to the variables we define in our preprocess function, the most important of the variables is provide automatically to the theme: $rows. Style templates boil down to iterating through the $rows variable and spitting out some markup. We'll get to the style template in a minute. If you don't need any other variables other than $rows and $options and you don't need to modify these variables, can omit the preprocess function which will be fine for our simple style plugin.

It's very important to note that if you do use template_preprocess functions, they are defined outside your views_plugin class definition.

Our row plugin template_preprocess looks like this (inside views_json.inc but outside views_plugin_row_unformatted):

<?php
/**
 * Theme preprocess function for views-view-row-unformatted.tpl.php
 */
function template_preprocess_views_view_row_unformatted(&$vars) {
  $view = $vars['view'];
  //print('preprocess');
  // Loop through the fields for this view.
  foreach ($view->field as $id => $field) {
    if (!empty($field['handler']) && is_object($field['handler'])) {
      $object = new stdClass();
      $object->content = $field['handler']->theme($vars['row']);
      if (isset($field['handler']->field_alias) && isset($vars['row']->{$field['handler']->field_alias})) {
        $object->raw = $vars['row']->{$field['handler']->field_alias};
      }
      else {
        $object->raw = NULL; // make sure it exists to reduce NOTICE
      }
      if (!empty($vars['options']['separator']) && $object->content) {
        $object->separator = filter_xss_admin($vars['options']['separator']);
      }
      $object->handler = $field['handler'];
      $object->class = views_css_safe($id);
      $object->label = check_plain($field['handler']->label());
      $vars['fields'][$id] = $object;
    }
  }
}
?>

It looks more complex but it follows the same pattern as for a style plugin (remember Views 2 is very OO.) Row plugins automatically provide an array variable call $fields to the theme, which contains each field value and field label for the row to be rendered. They also have analogous render() and theme_functions() methods implemented in the base views_plugin_row class Before the plugin themes the row we can modify the $fields by modifying the $vars['fields'] array.

Upgrading from Views 1.x to Views 2: A user's perspective

Views 2 is the newest major release of Views specifically coded for Drupal 6. Views 2 retains all of the core functionality of Views 1, together with a completely revamped user interface, and a large set of new features which enhance the original feature-set of Views 1. This document is a side-by-side comparison of Views 1 vs. Views 2 from a user's perspective, detailing the UI changes, some new ways to perform old tasks, the cool new feature of Views 2 and how these features can be used to address some of the shortcomings of Views 1.

Admin interface

The first thing that pops out after you install Views 2 is the radically different admin interface:

Views 2 admin interface

compared to the old comfy Views 1 interface:

Views 1 admin interface

The new admin interface performs the same functions as the old - listing all the views in the system, providing links to add or import views and a link to Views Tools - but has been compacted, with each view displayed as a paragraph style-row compared to the table of Views 1 and set of filters on top to ease locating views among a large list.

Context-help is available by clicking the small blue question-mark icon. Context-help in Views 2 is provided by the Advanced Help module so make sure to install that together with installing Views 2. Context-sensitive help is available in many areas of the Views 2 module.

A couple new attributes of each view are visible in the filter header:

Tag - This is just another label for organizing and sorting views. Tags can be any text.
Display - In Views 1 each view query was tied to its display; in other words your fields, sorts, filters, and arguments could only be displayed in the single page or block display provided in the view definition. In Views 2, view displays have been decoupled from view queries - it is now possible to have multiple page, block, and feed displays from a single view. More on view displays later.
Type - Views 2 view types are radically different from Views 1 types. Views 1 types basically defined how the node list displays were styled - you had Full Nodes, Teaser List, Table View, and so on. In Views 2 view display styles have been broken out into the separate Style attribute. View types now refer to the primary table on which information for the query will be retrieved which controls what arguments,fields,sort criteria and filters are available. Views 2 view types are discussed later.

Adding a view

So let's jump in and add a view

Adding a view

The first step in adding a view is simply entering a name (only alphanumeric characters, no spaces,) a description, tag, and the view type. In this case we're going to create a view with user data.

Configuring the new view

This might be the 2nd whoa moment as the interface here is also completely revamped from Views 1.x. The best way to summarize is to say all the pieces from the Views 1.x interface are still there...just in different places. Fields, Arguments,Sort critera,and Filters are all there, just in new AJAXY-flavours
We can start by adding fields:

Adding fields

Clicking on one of the of Fields +widgets unfurls a section at the bottom of the page with all the available fields grouped by Comment, File, Node, Node revision, Taxonomy and User. This is a general paradigm for the Views 2 interface - clicking on a widget or link unfurls a section at the bottom of the page with the relevant interface. In this case you can use the Groups drop-down box to show only a subset of the fields available according to the above groups, or select All to see all fields available. In the shot below, clicking on the Add button for our fields brings up the familiar jQuery "wait" animation as the fields we selected are added to the interface

Adding fields

Once we add our fields they show up in the Fields section of the interface where they can be rearranged by clicking the up/down widget. We can also remove a field using the same interface:

Rearranging fields

Making a change to usually triggers a refresh of the view preview conveniently located right below the main interface:

Views preview

Now that we have some fields setup we can turn our attention to Basic Settings for the view.
It's important to note that all the interface elements pertain to the current Display selected for the view. As mentioned before a view can have multiple displays. The first time you create a view you'll be manipulating the Default display. You can add displays using the Add Display button; this lets you have as many displays of a view as you would like all sharing the same Fields, Sort Criteria, Filters and Arguments but using different types of displays like Page, Feed, Block and Attachment.

Adding a Page display

Let's stick with the Default display and twiddle some settings. We can set the Title to "User View 1" and the Style to Table. As mentioned earlier, view styles in Views 2 correspond more to view types in Views 1.

Selecting a Views 1 View Type

In Views 2, view styles control how a view display looks.

Selecting a Views 2 Display Style

We're given the style options of Grid, List, Table and Unformatted. Additional display styles can be added by Views style plugins. Choosing a style reveals a "settings" button which you can click to configure the style you've chosen. In the shot below we've selected and are configuring the Table style:

Selecting and configuring the table style

We won't set any options other than the defaults. Now we can click the preview button to get a live preview of what our view looks like:

Live preview

Notice that in addition to the view, we can also see the SQL query that the view is using. This is really useful in debugging complex view queries.
We can add a filter by clicking on the Filters+ widget which unfurls the filters interface:

Adding filters

You can select the field you want to filter on, as well as the filter operator and the filter string:

Configuring filter

Sort criteria are added by clicking on the sort criteria + widget:

Configuring sort criteria

@TODO relationships and arguments

Anytime we update sort criteria or filters or any element of the view, it triggers a refresh of the live preview. We can get a look at the view we've defined at anytime by clicking on the Preview button. Here we have defined an ascending sort, and we filter on e-mail addresses starting with c:

View preview

Now that we have defined our view we would like to be able to access it from somewhere other than the Views interface. In Views 1 you would use "Add Page View" to set a URL for the view:

Views 1 add page view

In Views 2 you specify how and where you want to display you view by adding Views displays
to your view. If we look at the add display drop-down:

Views 2 display types

The page display the view as a Drupal page with its own URL and menu entry.

Page display options

Upgrading from Views 1.x to Views 2.x: A developer's perspective

hook_views_tables() is now hook_views_data()

The new name for hook_views_tables() is hook_views_data(). That's about where their similarity ends.

Views 1.x:

<?php
function example_views_tables() {
  // ...
  return $tables;
}
?>

Views 2.x:

<?php
function example_views_data() {
  // ...
  return $data;
}
?>

Base (new in 2.x)

While Views 1.x could only display lists of nodes and node-related properties, Views 2.x allows modules to define their own top-level type that may be listed.

<?php
function example_views_data() {
  // ...
  $data[$table_name]['table']['base'] = array(
    'field' => $primary_key,
    'title' => t($human_readable_name),
    'help' => t($human_readable_description),
  );
  // ...
  return $data;
}
?>

Here's an example from comment.views.inc:

<?php
function comment_views_data() {
  // ...
  $data['comments']['table']['base'] = array(
    'field' => 'cid',
    'title' => t('Comment'),
    'help' => t("Comments are responses to node content."),
  );
  // ...
  return $data;
}
?>

This results in "Comments" being one of the "View types" available when creating a view.

Table definition

In Views 1.x, you needed to specify the 'name' and 'provider' of a table. In Views 2.x, only the name is specified, along with a 'group' that determines how its properties are grouped in the UI.

Views 1.x:

<?php
  $tables['book'] = array(
    'name' => 'book',
    'provider' => 'internal',
    // ...
  );
}
?>

Views 2.x:

<?php
  $data['book']['table']['group']  = t('Book');

// ... ?>

Joins

The syntax for specifying table joins has changed.

In Views 1.x, you would specify both the left and right side of a join in a full array syntax. Views 2.x uses a shorter-hand version.

Views 1.x:

<?php
    // ...
    'join' => array(
      'left' => array(
        'table' => 'node',
        'field' => 'vid'
      ),
      'right' => array(
        'field' => 'vid'
      )
    ),
    // ...
?>

Views 2.x:

<?php
  $data['book']['table']['join'] = array(
    'node' => array(
      'left_field' => 'nid',
      'field' => 'nid',
    ),
  );
?>

Views Developers

Views Theming Documentation

merlinofchaos — Mon, 21 May 2007 19:49:35 +0000

This is an effort to get people in the community to do some work for me. Maybe I'm a bit lazy, but this is a piece of work that I've admitted I'm simply never going to get to. Yet it is needed.

This document is intended to be a comprehensive documented on theming Views. It should cover all of the basics, and it should also include tutorials. It really needs to be both.

I want to start with a topic list. I'm not even sure the best way to lay this out, so I'm going to start with the really obvious topics:

This is a WIKI page. I welcome people to edit this document. Ideally, once parts of this document are ready they can be moved to drupal.org, but this is an excellent place to work from.

How Views are themed, in general: TODO
How to theme a basic view: TODO
How to theme a single field for a view: TODO
How to write a Views plugin: TODO

Overview

The term "Views Theming" covers a range of activities around formatting Views output. These include:

CSS: The Views output contains a rich set of div tags allowing fine-grained CSS control over the output.
List View Item Formatting: With example code provided by the Views Theme Wizard a PHP template file can be used to format the output of a list view.
Node/Teaser View Formatting: The Node and Teaser View types use the "native" formatting of the nodes being displayed. Data in these views are themed via the node templates of the nodes being displayed. e.g., node.tpl.php

default views list output

Views outputs list views as a series of divs and an unordered list. These allow you to use css selectors to target all views and fields on your site, or just the specific views and fields in the specific view you're working on. It's possible to quite radically alter how list views appear just by carefully targeting css at the various elements.

For the purposes of this example, we'll use a list view called "example_list" using the following fields, and assuming it's displaying as a page:

Image (from imagefield/cck, we'll call our image field "field_photo")
node title (as link)

Viewing the page source of your view will show the structure of your view, it begins with:

<div class="view view-example-list">

This gives you the css selectors .view and .view-example-list. Applying styles to .view will affect all views site-wide, applying styles to .view-example-list affects just our example_list view. Just about every div in a list view contains two classes in this format - one for every view (or field), and one for the specific view or field you're working with.

If your view has a header, the next thing you'll see is:

<div class="view-header view-header-example-list">

.view-header will select every header in every view, .view-header-example-list will... hopefully you get that bit by now.

Then we get to:

<div class="view-content view-content-example-list">

which follows the same format.

Within view-content we get the list itself. It's at this point where the fields you selected when creating the view actually get output in an unordered list. The unordered list, the entire result set, and each individual field all get wrapped in divs for easy css selection.

In our example, all of this code appears just before the <img> tag.

<div class="item-list"><ul><li><div class='view-item view-item-example-list'><div class='view-field view-data-node-data-field-photo-field-photo-fid'>

Looks confusing doesn't it? Well it's not so bad.

.item-list wraps the unordered list, this allows any styles for .item-list in your theme to be overridden by .view .item-list

Then an unordered list wraps all the results, with each row (usually node) appearing as a list item (within one set of <li></li> tags.)

Often, you'll want to remove bullet points from unordered lists in views, you can do this using:

.view-example-list ul li {
  list-style-image: none;
  list-style-type: none;
}

Each row of results also gets enclosed in a div as well as the unordered list:

<div class='view-item view-item-example-list'>

At this point, we get to the very first field output by your view, since field_photo was at the top of our field selection, it gets printed first:

<div class='view-field view-data-node-data-field-photo-field-photo-fid'>

At this point views stops outputting classes for .all-views .your-view, and switches to .all-fields .your-field. This allows you to define the behaviour of fields across a number of different views, for example floating an imagefield left in any list view on your site.

To do this, we could use

.view-data-node-data-field-photo-field-photo-fid img {
float: left;
}

Or to float the image left in our example view, but leave it unaffected everywhere else, we could use:

.view-example-list .view-data-node-data-field-photo-field-photo-fid img

or just

.view-example-list img

if there's just the one image field.

The next set of code is for the node title:
<div class='view-field view-data-node-title'>
Note that .view-field is repeated, applying to any field of whatever type, and that .view-data-node-title applies to all instances of node-title.

By now, you should have an understanding of what each set of divs represents, and how to target css at individual fields.

If you want to theme your page view one way, and blocks slightly differently, you can add .block to any of the above selectors (i.e. .block .view .item-list) assuming your block.tpl.php uses <div class="block"></div> to wrap blocks.

Views Developers

Do not show first item.

timmillwood — Tue, 12 Aug 2008 14:38:22 +0000

I have created a view in Views 2 as an attachment, I don't want to show the first item. Is this possible?

My use case is the home page of http://www.millwoodonline.co.uk (sorry about the theme, it's a rough draft)

Views Developers

List View Without the List? Simple View for d5!

mgparisi@drupal.org — Tue, 12 Aug 2008 06:41:18 +0000

How hard would it be to make a view that was like the list view, but instead of

<ul><li></li><ul>

we simply do

<div id="xxx1" class="xxx"><div id="xxx1-1" class="xxx">data</div></div>?

Im going to TRY and do this, its a Simple View! This would be an excellent learning tool for both v1 and v2, since it would be a simple module that does one simple task! But honestly I have no Idea how to start!

Views Developers

Advanced search form

Julien Marboutin — Wed, 16 Jul 2008 15:21:16 +0000

Another common need I think :

Lot of us have a View page that list CCK nodes and which have exposed search filters. Don't you ?

But which filters to expose if they are many ?

Maybe it can be a good idea if we can set that some exposed filters are available in a kind of "group field set" for more advanced research or even on a separate "advanced search" page.

Views Developers

Create a view of taxonomy linking to something else (photogallery)

alexic@drupal.org — Thu, 10 Jul 2008 14:04:59 +0000

Hello everybody,

I followed the tutorial on drupal.org about creating a photogallery with cck, views, image_field etc.

To have different photogalleries I set up different terms for the vocabulary "Photogallery-v".
Each terms is associated to an image trought the module "taxonomy image".

I created the views for the single galleries (actually is a parametric view) in the form /photogallery/

Now, i would like to create a block-page-something that will list the last galleries on the site, showing up the taxonomy associated image.

I tried to create a view of taxonomy. But there's a small problem.

How can I link the taxonomy link on the block to the photogallery view?

Thanks folks,
Fabio

Views Developers

Search agent

Julien Marboutin — Wed, 09 Jul 2008 09:52:02 +0000

Have you ever used a search agent on a job market site for example ?

As a user, you can define key words and be alerted by email when new contents that match your criterias appear on the site.

Is there people working on a kind of general search agent working with CCK and Views ?

Please let me know if you are working on this or if you would like to work on this because I know someone that is willing to pay for this functionnality this summer for a site working with Drupal 5 and Views.

Thanks,

Ps : do you think it will be easy to develop it both for drupal 6 and 5 ?

Views Developers

Trouble creating a custom sort function for a CCK type

ultimike@drupal.org — Tue, 08 Jul 2008 19:56:04 +0000

Hello,

I'm trying to figure out the best way to use the Views (v1.x) API to create a custom sort function for a CCK type.

Here's what I have:

CCK fields:

title (string)
rating_a (int)
rating_b (int)
rating_c (int)
rating_d (int)

I need to develop a way to sort the view by the average of a variable number of the "rating" CCK fields.

For example, if the user wants to sort the nodes only by "rating_a" and "rating_c", then the "order by" clause would look something like this:

...ORDER BY (rating_a + rating_c)/2 DESC

Or, if the user wants to sort the nodes by "rating_b", "rating_c", and "rating_d", the order clause would look like this:

...ORDER BY (rating_b + rating_c + rating_d)/3 DESC

Make sense so far?

The various "rating_*" choices will be coming in via arguments in the form "rating_a+rating_b+rating_c". So far, my plan has been to hook_views_arguments to define the argument, then to write a custom handler. In the custom handler, I'm planning on using $query->add_orderby() in the "filter" $op to actually add the sort criteria.

The problem I'm having is that I'm not sure what to set the add_orderby() parameters to:

add_orderby($table, $field, $order, $alias = '')

When I look at the $query coming into the custom handler, I don't see any of the CCK tables joined. I know that at some point the CCK tables will be there, but it seems that when my module's hooks are called, the CCK stuff hasn't been added yet.

Am I taking the correct approach on this or am I going about this the wrong way? Any help would be appreciated.

Here's a (simplified) copy of the code:

/**
 * Implementation of hook_views_arguments.
 */
function mymodule_views_arguments() {
  $arguments = array(
    'ratings' => array(
      'name' => t('Ratings'),
      'handler' => 'mymodule_views_handler_rating',
      'help' => t('This argument sorts the results based on the ratings inputs.'),
    ),
  );
  return $arguments;
}

/** * Implementation of hook_views_handler_arguement. */ function mymodule_views_handler_rating($op, &$query, $a1, $a2 = null) { switch ($op) { case 'filter': dsm($query); //$query->add_orderby($table, $field, $order, $alias = '') break; } }

Views Developers

Creating template for fields in colums

vistree — Mon, 07 Jul 2008 16:19:12 +0000

Hi all,
tried to figure out how to create a template to publish fields in different colums.
For each row there are several fields. Now I don't want to put them one after the other. Instead I want to put them in 3 colums. So it is a little bit like the already existing grid-view. But instead of displaying "rows" next by next I want to put fields in the colums.
Is there a way to do it?
Thought about creating my own template as a copy of the views-view-grid.tpl.php and putting the names of the fields in this directly. But did not work (as I don't know how to call the fields in a view).

What do you suggest?
Regards

Kai

Views Developers

Building a view from a different source (not Database)

drunken monkey@drupal.org — Tue, 01 Jul 2008 15:34:08 +0000

Hi, everyone!

I'm doing a GSoC project to improve the apachesolr module (See here for details). Core of the project is to find a way to create a view showing results from a Solr search query. And this is where I could use some ideas from people more experienced with Views than me.

As you know, Views dynamically builds an SQL query which returns the objects to display. But since the Solr search data is not in the database, and also has no SQL interface, Views can't be easily used to display objects from this or similar sources.

I've already found (and published, see apachesolr HEAD) one workaround: a filter which inserts Solr's search results as a "WHERE node.nide IN (...)" into the Views query. It should also be possible to change this to an argument, so it does not only work on the Solr search results page but also as an independent page, executing the query itself.
This approach still has some drawbacks:

The Views query as well as the Solr search have to be executed, decreasing performance.
In the current state, adding additional filters to the view decreases the number of results displayed, since the apachesolr filter filters out exactly ten results (the actual number is configurable). It might even show no results at all, when there really would be some.
Currently, a workaround is to set the number of results displayed by Solr to a higher number than that of the view, but to completely remedy this one would have to use a Solr search without result limit, further dropping performance.

One idea from my mentor and maintainer of the apachesolr module would be to first execute the Views query and then pass the returned nids to the Solr query, but this would have the same problems as the current approach. Moreover, I think that because a search typically returns less nodes than most filters, the effects of the second problem will be far more pronounced this way, unless Solr is really good with such things. However, it remains to be tested.

One other idea I've got would be to create the view programmatically and replacing the call to $view->execute() with an equivalent custom function. But then the problem would be that either that function would have to parse the SQL query (or at least make a good attempt) and translate it to one for Solr, or the view couldn't use any predefined filters. In the latter case, it would operate on a new fictional "apachesolr" base table, maybe with an own way to define filters.

So, as you can see, all approaches I can think of have more or less serious flaws.
Which one would you use? Can you think of additional ones, or improvements to the existing? What are your thoughts on the whole subject? What advice do you have?

Thanks in advance for your responses!

PS: Oh, and this uses Views 2, before you ask.

Views Developers