227 lines
8.0 KiB
HTML
227 lines
8.0 KiB
HTML
In order to take advantage of the changes in Drupal 7, Views has gone through several API changes.
|
|
Here's what you should know.
|
|
|
|
<h3>Handler registry</h3>
|
|
|
|
Views now uses Drupal's dynamic-loading code registry.
|
|
You can safely remove your implementations of hook_views_handlers(), since they are no longer used.
|
|
|
|
Please remember to specify the handlers in your module's .info file. For example:
|
|
<pre>
|
|
name = Example module
|
|
description = "Gives an example of a module."
|
|
core = 7.x
|
|
files[] = example.module
|
|
files[] = example.install
|
|
|
|
; Views handlers
|
|
files[] = includes/views/handlers/example_handler_argument_string.inc
|
|
</pre>
|
|
|
|
<h3>Removed handlers</h3>
|
|
|
|
Note that views_handler_filter_float has been removed.
|
|
This functionality is now handled by views_handler_filter_numeric.
|
|
There's no need for having a special handler any more, thanks to the new DB layer in Drupal 7.
|
|
|
|
views_handler_sort_formula has been removed.
|
|
Everyone who used it can extend from views_handler_sort, too.
|
|
|
|
<h3>Ctools dependency</h3>
|
|
Views requires ctools now, so it can use the dependency system of ctools.
|
|
The only thing you have to do is to remove views_process_dependency.
|
|
|
|
<h3>Changed add_where api</h3>
|
|
If your field is a plain sql field:
|
|
<pre>
|
|
$this->query->add_where($this->options['group'], "$this->table_alias.$this->real_field " . $this->operator . " '%s'", $this->value);
|
|
</pre>
|
|
has to be converted to
|
|
<pre>
|
|
$this->query->add_where($this->options['group'], "$this->table_alias.$this->real_field", $this->value, $this->operator);
|
|
</pre>
|
|
If your field is a complex where condition:
|
|
<pre>
|
|
$this->query->add_where($this->options['group'], "$upper($field) NOT LIKE $upper('%%%s')", $this->value);
|
|
</pre>
|
|
has to be converted to
|
|
<pre>
|
|
$placeholder = $this->placeholder();
|
|
$this->query->add_where_expression($this->options['group'], "$field LIKE $placeholder", array($placeholder => '%' . db_like($this->value)));
|
|
</pre>
|
|
placeholder() generates a automatic unique placeholder for you.
|
|
|
|
add_where with operator 'formula' can be converted to add_where_expression.
|
|
add_having with operator 'formula' can be converted to add_having_expression.
|
|
|
|
<h3>Changed place for display specific settings</h3>
|
|
In the new ui the new place for display settings is at the top of the second column.
|
|
Therefore use something like this code in your display plugin:
|
|
<pre>
|
|
$categories['block'] = array(
|
|
'title' => t('Block settings'),
|
|
'column' => 'second',
|
|
'build' => array(
|
|
'#weight' => -10,
|
|
),
|
|
);
|
|
</pre>
|
|
|
|
<h3>Changed filter settings and associated class variables</h3>
|
|
'optional' and 'single' are now 'required' and 'multiple', the logic is now opposite.
|
|
Also, the 'no_single' and 'no_optional' class variables (known as "object flags" in the API docs)
|
|
are now 'always_multiple' and 'always_required'.
|
|
|
|
<h3>Changed argument settings</h3>
|
|
See the init() function in views_handler_argument for an overview of everything
|
|
that changed.
|
|
|
|
1. The default actions 'summary asc', 'summary desc', 'summary asc by count', 'summary asc by count'
|
|
have been replaced by a single 'summary' action (which takes the sort order and type as options).
|
|
2. Wildcards are now called exceptions.
|
|
<pre>
|
|
$this->options['exception']['value'] = $options['wildcard'];
|
|
$this->options['exception']['title'] = $options['wildcard_substitution'];
|
|
</pre>
|
|
3. Summary plugin options are now stored in 'summary_options' instead of 'style_options'
|
|
<pre>
|
|
$this->options['summary_options'] = $options['style_options'];
|
|
</pre>
|
|
4. The selected summary plugin is no longer stored in 'style_plugin'.
|
|
<pre>
|
|
$this->options['summary']['format'] = $options['style_plugin'];
|
|
</pre>
|
|
5. The validator options have been moved.
|
|
<pre>
|
|
$options['validate']['type'] = $options['validate_type'];
|
|
$options['validate']['fail'] = $options['validate_fail'];
|
|
</pre>
|
|
6. The validator settings have been moved from $form['argument_validate'] to ['validate_options']
|
|
This means that dependent code in validate plugins needs to change.
|
|
Example change for views_plugin_argument_validate_user:
|
|
<pre>
|
|
$form['roles'] = array(
|
|
'#dependency' => array(
|
|
- 'edit-options-argument-validate-user-restrict-roles' => array(1),
|
|
+ 'edit-options-validate-options-user-restrict-roles' => array(1),
|
|
),
|
|
</pre>
|
|
|
|
<h3>The introduction of get_value() and sanitize_value()</h3>
|
|
The views_handler class got two new functions:
|
|
<pre>
|
|
/**
|
|
* Get the value that's supposed to be rendered.
|
|
*
|
|
* @param object $values
|
|
* An object containing all retrieved values.
|
|
* @param string $field
|
|
* Optional name of the field where the value is stored.
|
|
*/
|
|
function get_value($values, $field = NULL) {
|
|
$alias = isset($field) ? $this->aliases[$field] : $this->field_alias;
|
|
if (isset($values->{$alias})) {
|
|
return $values->{$alias};
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Sanitize the value for output.
|
|
*
|
|
* @param string $value
|
|
* The value being rendered.
|
|
* @param string $type
|
|
* The type of sanitization needed. If not provided, check_plain() is used.
|
|
*/
|
|
function sanitize_value($value, $type = NULL) {
|
|
switch ($type) {
|
|
case 'xss':
|
|
$value = filter_xss($value);
|
|
break;
|
|
|
|
case 'url':
|
|
$value = check_url($value);
|
|
break;
|
|
|
|
default:
|
|
$value = check_plain($value);
|
|
break;
|
|
}
|
|
return $value;
|
|
}
|
|
</pre>
|
|
These functions are meant to be used in the render() functions of field handlers,
|
|
for fetching data (usually by alias) from the $values object, and for sanitizing values.
|
|
|
|
The abstraction of fetching data from rendering data is important because
|
|
different query backends have different ways of storing data in $values, and the field alias
|
|
is a SQL specific thing. So instead of overriding the whole render() function and copying
|
|
all of the logic there (as well as having to constantly keep up with upstream Views changes),
|
|
the backend can just override get_values(), which is significantly less code.
|
|
|
|
Of course, different ways of fetching and displaying data might require different
|
|
ways of sanitizing it, hence the usage of the sanitize_value() function.
|
|
|
|
Examples of converting render() field handler implementations:
|
|
<pre>
|
|
// This
|
|
$value = $values->{$this->field_alias};
|
|
// Becomes this
|
|
$value = $this->get_value($values);
|
|
|
|
// And this
|
|
$format = $values->{$this->aliases['format']};
|
|
// Becomes this
|
|
$format = $this->get_values($values, 'format');
|
|
|
|
// Instead of this:
|
|
return check_plain($value);
|
|
// We write:
|
|
return $this->sanitize_value($value);
|
|
|
|
// Since sanitize_value() supports different sanitization functions, this:
|
|
return filter_xss($value);
|
|
// Can become:
|
|
return $this->sanitize_value($value, 'xss');
|
|
</pre>
|
|
|
|
|
|
<h3>Changed views_get_page_view</h3>
|
|
In contrast to 6.x views_get_page_view now does stores the current view, not the current page display.
|
|
|
|
<h3>Removed views-view-row-node</h3>
|
|
Due to changes in comment.module there is no extra views-view-row-node template needed to display the comments. If you do some custom stuff there you should now be able to do everything in your node.tpl.php.
|
|
|
|
<h3>Entity type Key on Base tables</h3>
|
|
During the development of the drupal7 version of views the entity type associated with a table got added to $data['name']['table']['base']['entity type']. It should be moved to $data['name']['table']['entity type'].
|
|
|
|
<h3>Changed views_plugin_style::render_grouping()</h3>
|
|
The parameters as well as the structure of the methods return have changed.
|
|
The method now accepts a third optional parameter called "$group_rendered".
|
|
This parameter defines whether to use the rendered or the raw field value for grouping.
|
|
Intention for adding the parameter was that the grouping could have been acted
|
|
unexpected if the rendered field contained unique values e.g. by using drupal_html_id().
|
|
<dl>
|
|
<dt>New return structure</dt>
|
|
<dd>
|
|
{grouping value} is the value affected by the new parameter.
|
|
<pre>
|
|
array (
|
|
{grouping value} => array(
|
|
'group' => {rendered_value of the grouping field},
|
|
'rows' => array({group rows}),
|
|
),
|
|
);
|
|
</pre>
|
|
</dd>
|
|
<dt>Old return structure</dt>
|
|
<dd>
|
|
<strong>If the new parameter isn't explicitly set or its value is NULL the structure of the return will be the same as in D6!</strong>
|
|
<pre>
|
|
array (
|
|
{rendered_value of the grouping field} => array({group rows}),
|
|
);
|
|
</pre>
|
|
</dd>
|
|
</dl>
|