0

I have a view that list some items depending on the current node loaded. I also want to add few exposed filters to the view. The exposed filters cannot be shown to users directly. I want to provide a separate set of filters (to display) for users and based on what user selected, I want to set one or more filters of the view.

For example: I want an option for user to show only nodes that are not older than 7 days, 14 days etc so I will provide a list with All, 7 days, 14 days etc and when user select any of these, I want to set the exposed filter for node created time and with the calculated value - the date 7 days or 14 days or so from now.

There are several filters like this - ie based on what the user selected, we need to apply different filters in view.

To implement this, I plan to implement a block, in which I can programmatically call a view 

$my_view_name = 'the_view';
$my_display_name = 'block';
$my_view = views_get_view($my_view_name);
$my_view->set_display($my_display_name);

if ($option == FIRST_OPTION) {
  $my_view->exposed_input['filter1'] = $option1_calculated_value1;
  $my_view->exposed_input['filter2'] = $option1_calculated_value2;
}  
else {
  $my_view->exposed_input['filter1'] = $option2_calculated_value1;
  $my_view->exposed_input['filter2'] = $option2_calculated_value2;
  $my_view->exposed_input['filter3'] = $option2_calculated_value3;
}  

$my_view->execute(); 
unset($my_view->exposed_widgets);
return $my_view->preview();

Is there any problem in using this method? Is there any other way to do this? Is there any performance implications in using this method? Will views caching etc work in this case? I use Drupal 7 and Views 7.x-3.7

Improve this question
5
  • I'm not really sure if I understand what you want, because if I do, you can set it up using Views UI alone, without a single line of code. Or if you want fixed list of preset values, you could just change the form a bit with hook_form_alter, and let the views do the rest. But the way you described might work, too.
    – Mołot
    Dec 11, 2013 at 7:51
  • 1
    Welcome to Drupal Answers :) Just a bit of advice in this area - if you have a problem, then try to fix it. But until then, there's no point prematurely and hypothetically optimising your code. Why do you think there will be performance problems? Testing whether caching works with this method is easy, have you tried it? The bottom line is: no-one can tell you if your code, on your server infrastructure, will cause an unspecified level of performance issues when under load from an arbitrary level of traffic. Only you can come to those conclusions, after sufficient testing
    – Clive ♦
    Dec 11, 2013 at 10:22
  • Thanks for the reply. I will not be able to use views UI directly as I have a set of presets, each apply to different filters. @Clive Thanks for you advice. I will test this. BTW did you see any obvious problem in this approach? Calling views in a block and apply filters as required than using a views exposed filter form?
    – Vimal
    Dec 11, 2013 at 12:57
  • @vimal Nope, no obvious problem there that I can think of - the results of view::execute() will probably be cached, and the block itself is open to render caching, so your only 'hit' is the DB query and Views processing. The only way you'd do it quicker is to write and process the query manually, I guess, bypassing the Views overhead
    – Clive ♦
    Dec 11, 2013 at 13:05
  • 1
    @Clive Thanks. I've avoided direct query to expose the configuration options provided by the Views UI to the site admin. Any case, I will try the view method itself and see how it performs. If it is not working as expected, then will think of write and process the query manually.
    – Vimal
    Dec 11, 2013 at 13:19

1 Answer 1

Reset to default
1

Definitely not an issue unless you overload the view (but you can do that with the UI also - so no difference there).

On our production architecture we have views UI disabled and all the views are in code under version control however we also have a content team that needs to build 'lightweight views' that pull data from a product catalog and displays it in a particular way. Unfortunately we don't want them running direct SQL or using views UI as they don't completely understand what it all means so we just programmatically create these views and expose a UI to them that they understand. Things like:

  • What design they want on it
  • How they want the sorting of the dataset
  • Whether they need 'no results' text
  • etc.

Some caveats to doing more complex versions of this are:

  • Looking out for timing issues. I.e. not having an option available at that call point
  • Ensuring the correct structure is used. Example: $view->use_ajax vs $view->display[$dispay_id]->filters['use_ajax'].

Neither the less, it is all definitely possible and scales without issues.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.