first import
This commit is contained in:
Bachir Soussi Chiadmi
224
sites/all/modules/views/help/api-upgrading.html
Normal file
224
sites/all/modules/views/help/api-upgrading.html
Normal file
@@ -0,0 +1,224 @@
|
||||
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 $values
|
||||
* An object containing all retrieved values.
|
||||
* @param $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 $value
|
||||
* The value being rendered.
|
||||
* @param $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>
|
||||
Reference in New Issue
Block a user