attachments should (optionally) inherit the exposed filters from parent display
aclight - June 22, 2008 - 19:45
| Project: | Views |
| Version: | 6.x-2.x-dev |
| Component: | exposed filters |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
An attachment display should be able to (optionally) inherit the exposed filter settings from the display on which the attachment is attached to. This should work similarly to how it's possible to specify that an attachment will inherit the arguments. It would also be best for this to behave similarly to how attachments work in that the filter settings of the parent display would always be copied to something like original_exposed_filter_data.
#1
I took a look at this but got stuck. I modified the beginning of the attach_to() function of views_plugin_display_attachment to look like so:
<?php
function attach_to($display_id) {
$displays = $this->get_option('displays');
if (empty($displays[$display_id])) {
return;
}
// Get a fresh view because our current one has a lot of stuff on it because it's
// already been executed.
dsm($this->view->exposed_data);
$view = $this->view->clone_view();
$view->original_args = $view->args;
dsm($this->view->exposed_data);
?>
When I created a simple view (below) and went to the page, and then set a filter and hit the apply button, both of these dsm() calls print out an empty array.
<?php$view = new view;
$view->name = 'simple';
$view->description = '';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = '0';
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('filters', array(
'type' => array(
'operator' => 'in',
'value' => array(
'project_project' => 'project_project',
),
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'id' => 'type',
'table' => 'node',
'field' => 'type',
'relationship' => 'none',
),
'tid' => array(
'operator' => 'or',
'value' => array(),
'group' => '0',
'exposed' => TRUE,
'expose' => array(
'use_operator' => 0,
'operator' => 'tid_op',
'identifier' => 'tid',
'label' => 'Taxonomy: Term ID',
'optional' => 1,
'single' => 1,
'remember' => 0,
'reduce' => 0,
),
'type' => 'select',
'vid' => '1',
'id' => 'tid',
'table' => 'term_node',
'field' => 'tid',
'hierarchy' => 0,
'relationship' => 'none',
'reduce_duplicates' => 0,
),
));
$handler->override_option('access', array(
'type' => 'none',
'role' => array(),
'perm' => '',
));
$handler->override_option('row_plugin', 'node');
$handler = $view->new_display('page', 'Page', 'page_1');
$handler->override_option('path', 'simple');
$handler->override_option('menu', array(
'type' => 'none',
'title' => '',
'weight' => 0,
));
$handler->override_option('tab_options', array(
'type' => 'none',
'title' => '',
'weight' => 0,
));
$handler = $view->new_display('attachment', 'Attachment', 'attachment_1');
$handler->override_option('displays', array(
'page_1' => 'page_1',
'default' => 0,
));
?>
#2
I think the problem here is that attach_to() (line 2541 of plugins.inc) is called before views_exposed_form_submit() is called (line 875 of views.module), which puts the selected values into $view->exposed_data.
#3
From chatting in IRC, I'm told that I need to modify the attachment's "uses_exposed" setting in views_plugin_display_attachment::uses_exposed() to respect the new flag that I'll add.
#4
Here's a patch that implements what we discussed in IRC. I tested locally and it seems to work well and gives me the desired results.
#5
Great work! THanks!
#6
I've noticed now that if I have two views that are identical in every way except for one view the attachment display is set to inherit exposed filters and on the other view exposed filters are not inherited, when running the view that *does* inherit the exposed filters, I get some warnings and the view isn't built correctly.
The notices are:
* warning: Invalid argument supplied for foreach() in /Applications/MAMP/htdocs/port/drupal/sites/all/modules/views/includes/handlers.inc on line 517.* warning: array_merge() [function.array-merge]: Argument #1 is not an array in /Applications/MAMP/htdocs/port/drupal/sites/all/modules/views/includes/handlers.inc on line 449.
I tried to figure out what's going on here but couldn't follow what was going on completely.
The problem seems to be in views_many_to_one_helper::ensure_my_table() on line 511:
<?php$this->handler->view->many_to_one_tables[$field] = $this->handler->value;
?>
The first time this line is executed, $this->handler->value = array(0 => 42). However, the second time the same line is executed, $this->handler->value = 42. So in other words, in the first case it's an array, in the second case it's a string. However, I couldn't figure out how this is getting set to be a string on the second run through.
I'll be around most of today, so if you need me to put this latest code on my dev site and add some dsm() for debugging ping me in IRC.
The view I'm getting this problem with is the very complicated one with the project_release relationship, etc. so just pasting the exported view here might not be much good, though I can do that as well if you wish.
#7
Hmm. The processing in accept_exposed_input is supposed to make that into an array. It's interesting that it doesn't happen on the attachment. I'm not sure why that might be, since they're both getting the input well before the form is actually processed. Will see if I can figure this out.
#8
Ok, so in the case where I'm inheriting filters (and getting the warnings), views_handler_filter_term_node_tid::exposed_validate() gets executed only once, however views_handler_filter_term_node_tid::accept_exposed_input() is executed twice. The first time, $this->validated_exposed_input has a value (an array) and therefore is used to pupulate $this->value. The second time around, $this->validated_exposed_input is not set, and therefore $this->value isn't changed and remains the same value that views_handler_filter::accept_exposed_input() puts into it, which is a string and not an array.
Hopefully this info helps a bit.
#9
Huh! Thanks, that is helpful.
#10
This turned out to be an issue with FAPI that prevented multiple validate calls on the same form. I added an override and moved the function into views version of form.inc. Not ideal but there's LOTS of fodder in here for inclusion into Drupal core. =)
#11
Theres a core issue about this at http://drupal.org/node/260934. I posted a reference to this issue there.
#12
#180063: No way to flush form errors during iterative programatic form submission is now RTBC. I marked Karen's as a dupe.
#13
Automatically closed -- issue fixed for two weeks with no activity.