I currently have a very large set of Views that I am refactoring. These views work with a set Taxonomy and pull in the content that links to that Taxonomy. However the work that I am doing in the refactoring is going to result in the following necessities, when the Taxonomy gets added/updated by the user, and there is a new View catering to the content that uses it:

  • Dynamically modifiable Taxonomy values
  • New path
  • New Global Text
  • New Views Block that acts as a Tally counting the usage

Removal of the Views when the Taxonomy item is deleted, without affecting the others in its group.

So what do you think I should be looking at to accomplish this? 

Hooks or handlers? 

Or ditch Views altogether, and only use it to help get the correct SQL in the mockup phase?

 

Accepted answer

It's a bit tricky to know based on your broad description. 

These suggest hooks to me:

  • Dynamically modifiable Taxonomy values
  • New path

This suggests a Views field handler to me: 

  • New Global Text

And this suggests "ditch Views" to me IF for some reason can't be accomplished by a Views block:

  • New Views Block that acts as a Tally counting the usage

Personally, I've used new Views handlers  when I need to create special filters, for example, that look up a global variable to filter by an entity's field value, or when I need a very specific way of sorting the query, or displaying the results of a field. Also, to avoid using the same Global text field in different views (think of creating a link to edit a custom entity listed in a view). 

I have used different Views hooks to load special Javascript or css files, to loop through the results and make changes before they are displayed. I try to stay away from hooks that modify Views queries, as those are terribly complex, and it's just faster to do the queries myself with db_select and then display the results in the ways I want.

I've ditched Views when queries are very complex that using a Views would get ridiculously difficult, when I need special treatments of the results that can't be provided by Views field rendering. In some of those cases I could have written a new Views plugin (which handles the display or query), but that would have been more work than just writing my own queries and handling the results in custom modules.

 

Most helpful answers

And, one more thought hahaha

You can learn A LOT about programmatically doing things to View (and Backdrop in general) by looking at the automated tests for Views etc.

Oh, one more thing. I did dare to modify Views dynamically (adding fields, grouping some fields into one column, and adding filters dynamically based on other conditions) on the fly at one point, and succeeded after a lot of sweat. Views are devilishly complex objects, and it's hard to know what to modify and when.

In my case, I used hook_views_pre_view() and an undocumented function called View::add_item(). A sample of what this code looked like for a filter added on the fly to a Views of an entity type called pursuit:

      $options_filter = array(
        'exposed' => TRUE,
        'value' => backdrop_map_assoc($pursuit_types_ids),
        'relationship' => 'pursuit',
        'expose' => array(
          'label' => ' Type',
          'operator' => 'type_1_op',
          'identifier' => 'type_1',
          'reduce' => TRUE,
          'multiple' => TRUE,
        ),
      );
      $view->add_item('page', 'filter', 'pursuit', 'type', $options_filter,'type_1'); 

A lot of the options above are gotten by inspecting an actual Views json file. Also, while there is no official documentation, you can find a few D7 modules that make use of View::add_item()and there was a short tutorial online somewhere.

EDIT: none of the above added items are permanent, unless you save the view programmatically, which I didn't do. 

Comments

It's a bit tricky to know based on your broad description. 

These suggest hooks to me:

  • Dynamically modifiable Taxonomy values
  • New path

This suggests a Views field handler to me: 

  • New Global Text

And this suggests "ditch Views" to me IF for some reason can't be accomplished by a Views block:

  • New Views Block that acts as a Tally counting the usage

Personally, I've used new Views handlers  when I need to create special filters, for example, that look up a global variable to filter by an entity's field value, or when I need a very specific way of sorting the query, or displaying the results of a field. Also, to avoid using the same Global text field in different views (think of creating a link to edit a custom entity listed in a view). 

I have used different Views hooks to load special Javascript or css files, to loop through the results and make changes before they are displayed. I try to stay away from hooks that modify Views queries, as those are terribly complex, and it's just faster to do the queries myself with db_select and then display the results in the ways I want.

I've ditched Views when queries are very complex that using a Views would get ridiculously difficult, when I need special treatments of the results that can't be provided by Views field rendering. In some of those cases I could have written a new Views plugin (which handles the display or query), but that would have been more work than just writing my own queries and handling the results in custom modules.

 

Oh, one more thing. I did dare to modify Views dynamically (adding fields, grouping some fields into one column, and adding filters dynamically based on other conditions) on the fly at one point, and succeeded after a lot of sweat. Views are devilishly complex objects, and it's hard to know what to modify and when.

In my case, I used hook_views_pre_view() and an undocumented function called View::add_item(). A sample of what this code looked like for a filter added on the fly to a Views of an entity type called pursuit:

      $options_filter = array(
        'exposed' => TRUE,
        'value' => backdrop_map_assoc($pursuit_types_ids),
        'relationship' => 'pursuit',
        'expose' => array(
          'label' => ' Type',
          'operator' => 'type_1_op',
          'identifier' => 'type_1',
          'reduce' => TRUE,
          'multiple' => TRUE,
        ),
      );
      $view->add_item('page', 'filter', 'pursuit', 'type', $options_filter,'type_1'); 

A lot of the options above are gotten by inspecting an actual Views json file. Also, while there is no official documentation, you can find a few D7 modules that make use of View::add_item()and there was a short tutorial online somewhere.

EDIT: none of the above added items are permanent, unless you save the view programmatically, which I didn't do. 

And, one more thought hahaha

You can learn A LOT about programmatically doing things to View (and Backdrop in general) by looking at the automated tests for Views etc.

Thanks man, you've convinced me; I'll bypass Views. :D