CTools caching integration

Blocks are not supposed to be rendered all the time, I need some more testing to (in)validate this is a bug.
Integration with CTools for Panels would a good thing, I'd need some time to see it through, but nice feature request.

In fact there is a weird behavior, I catch the blocks and replace them with an ESI or JS tag after they have been really built because I use the hook_block_view_alter(). I didn't find any other hook that allowed me to catch the blocks after (see esi_block.module, line 146). At this point in time, blocks are built, but not rendered.

Another solution would have been to alter the page rendering before the blocks are actually being built, then proceed to my own algorithm with it. This alteration would be too deep and it would actually maximize the chances to create compatibility problems with other modules, plus, it would remove the full core block handling part (it's not perfect, but it's working, so I can still actually rely on it).

Normally blocks returns their own caching policy (see between lines 73 and 93), this is where the caching policy is determined, once that done, the tag will carry a hash in get parameters which is actually computed against esi_api_build_tag() function parameters.

Where you didn't really see cache is because you probably didn't look at the right place. Check the esi_menu() implementation. You'll see there is a custom delivery callback and the esi_api_content_callback() callback as page callback, this were all the caching magic happens. Block are not cached the first time, they are cached the first asynchronous hit!

Ho, and PS: I'm open to any suggestions or improvements :)

sub!

Integrating with CTools would probably save a lot of code, and depricate the esi_block.module since CTools easily can render all sorts of stuff:

* Blocks
* Views
* Panel panes
* Page elements (site name, slogan etc)
* Custom text

I suggest that the ESI API module relies completely on the existing CTools plugin content_type. Adding the dependency on CTools is just a win, since it will exist on all D7 sites anyway, now when Views 3 depends on it.

The ESI API code base would be rather small and easy to maintain. I'll see if I can make a stab at this one soon.

Also, one could probably do quite smart stuff saving (caching) the context around the block since CTools has a rather nice context system.

Building on CTools would be great, dixon_ makes some excellent points. Big +1 here :)

sub

I wouldn't add CTools as a dependency for any reason in the world, but I can do a CTools integration if needed at some point, as optional shipped module, but I'll need help, so any volunteer to do some PoC or patches is welcome!

EDIT: @#6 And yes, I do sites without Views, and yes, they perform a lot better, and yes, writing a single SQL query is a lot faster than doing 50 clicks. If don't believe me, try by yourself.

@pounard: Wow, people do!? ;) I definitely believe you it is faster and more performant. No question about that.

@dixon: Yes, I am one of those people!

Seriously, I'm totally pro the CTools integration, but as an optional integration: as soon as I am able to free some time for it, I'll do, I keep this issue warm.

I'm setting it as "postponed", this doesn't mean it will die, please anyone with anough energy and time to do patches or PoC, do it!

I'm closing all issues for this module, please look at the ESI module which is now being maintained.