Would anybody be opposed to adding the post version of the views_pre_execute and views_pre_view hooks?

I need them for some custom results caching logic and don't think they would hurt.

I currently have:

Index: includes/view.inc
===================================================================
--- includes/view.inc	(revision 2903)
+++ includes/view.inc	(working copy)
@@ -745,6 +745,11 @@
     }
     $this->execute_time = views_microtime() - $start;
     $this->executed = TRUE;
+
+    foreach (module_implements('views_post_execute') as $module) {
+      $function = $module . '_views_post_execute';
+      $function($this);
+    }
   }
 
   /**
@@ -889,6 +894,12 @@
     // unset current view so we can be properly destructed later on.
     // Return the previous value in case we're an attachment.
 
+		// Let modules do something after views are run 
+    foreach (module_implements('views_post_view') as $module) {
+      $function = $module . '_views_post_view';
+      $function($this);
+    }
+
     if ($this->old_view) {
       $old_view = array_pop($this->old_view);
     }

Comments

merlinofchaos’s picture

merlinofchaos commented

If the whole purpose of this is to support custom caching logic, I would be very interested in seeing some of the @todo items I have in that part of the code filled in in order to facilitate caching, rather than adding a couple more process hooks, of which there are already several.

markus_petrux’s picture

markus_petrux commented

I guess it depends on what is going to be cached exactly? The view output? The result of queries? Also, if something is cached, when it would expire? When page cache is cleared? With a fixed expiration time? Something in views UI to configure caching options?

Do you have a caching strategy for views in mind?

merlinofchaos’s picture

merlinofchaos commented

I do!

For caching the query itself, the entire 'build_info' object needs to be cached. For caching results, we can cache either $view->result (and the associated build info) or the actual output from $view->render.

Now, individual handlers need to be able to exempt themselves from caching, but it would be nice if at least simple arguments can do what's necessary to cache. But this can come second.

The other part of the strategy is: Provide a caching plugin that works a bit like the style plugin. You select one on the view and it has a settings page. It should be able to detect if it thinks things are cachable. Then, the caching plugin has methods that can be called along various points of the view lifetime and they can be used to prevent parts of that view lifetime from running.

Cache clearing and dirtying is left 100% up to the plugin, like in Panels. By default Views could provide simple time-based caching like Panels does, but leave anything more sophisticated up to developers.

dalejung’s picture

dalejung commented

Hey Merlin,

I've only recently started poking into Drupal 6 and Views 2. So I'll have to poke around before I can comment on your caching strategy.

In Drupal 5, I have a patched version of Views that caches the $items array. It calls a hook and returns the cached $items array if it receives one. The caching granularity/invalidation is handled via a custom module called Signal Caching that keeps the cache fresh based off of events (voting, node adding, comments, etc).

I'm generally a fan of caching the final rendered output via Panels/Block cache (Which signal caching hooks into). However, being able to short circuit the querying of results in views has certain functional features. If you goto:

http://www.outdoorlife.com/photos/bragging-board/recent/single?bonnier_p...

You will see a photo gallery that does not use a delta. The next and prev links all reference the next and prev photo nid. This allows photo galleries to be bookmarkable and be resilient to re-ordering. This is all powered by views. Here's what going on:

1) User hits photo with in a gallery
2) Drupal calls the single photo view, which in turn calls the custom caching function
3) This function runs a Big view which is just the current view without the pager/node limit. The result set for this big view is also cached.
4) We then run through the cached array and locate the offset of the current photo, we also find the nid of the prev and next.
5) We return the single item array and the Single Photo View goes on normally without knowing where it's single result came from.
6) We also pass the prev/next/total items/current delta to the theme and then behold, deltaless galleries.

So I guess the hook isn't 100% about just caching. The reason I didn't completely write a new module to handle these galleries and just use views as a data model was that Views comes packed with so much built in. I know that Views 2 has done a lot of separate these features out, I'll see if I can get what I need without new hooks.

For what it is worth, there are plenty of pre hooks but no post hooks to support putting the collected output into cache.

Also, I'm a horrible communicator and I'm rushing this out before a meeting so sorry if I am being incoherent.

infojunkie’s picture

infojunkie
Location Vancouver
commented

I posted a similar request #599388: views_post_execute hook for another use case: manipulating $view->result right after execution. This is needed for Views Custom Field.

Thanks for your consideration.

merlinofchaos’s picture

merlinofchaos commented

If they're similar, can we combine them? One less duplicate issue? =)

infojunkie’s picture

infojunkie
Location Vancouver
commented

Already done. The issue filter doesn't seem to have picked it up :-)

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

#usenetnoob, i.e. subscribing.

esmerel’s picture

esmerel commented
Status: Active » Closed (fixed)

A bunch of caching stuff has been added to views - closing this issue as there's been no activity for 6 months

Anonymous’s picture

Anonymous (not verified) commented
Status: Closed (fixed) » Active

I reopen this issue: IMHO using a new hook called "views_post_execute" create a cleaner code than using "views_post_render". This feature is critical for Custom Field Views and Views PHP
You'll find the patch at #599388: views_post_execute hook
Please add this patch to the code.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (duplicate)

hook_views_post_execute exists and has existed for at least a year. It's even documented. Please do a little research before reopening old issues.

Chemtox’s picture

Chemtox commented

Sorry to insist on this, but I also stumbled into a broken Views PHP because it relies on views_post_execute, which Views 6.x-2.12 lacks. I'm guessing you're talking about Views 3, but to clarify, is Views 2 feature frozen and we'll have to "live with one more patch", or is there a Views 2 version with views_post_execute somewhere... possibly forcing me to finally get this git thing? :P

Cheers!