View caching

[448191]

How do you determine if a request is satisfiable from cache? I mean, without relying on application specific details like if a user is logged or something like that. It's for a framework, so relying on application details is not an option. Possibly I could have the application build on it provide the details required, but I prefer not to.

 

I'm thinking make a hash from all input (just serialize/hash $_REQUEST) as an identifier and don't cache if there's anything in $_SESSION... The latter has me a bit worried though, as this reduces the number of requests read from cache considerably.

 

Any pointers?

 

EDIT: something else. I've currently implemented caching of 'view updates', but the commands are still executed... I can cache the affected Domain Objects, or even the Command objects themselves (only if I somehow combine that with caching the associated view updates), but it somehow leaves me a bit confused.

[Eric_Ryk]

Almost never is a whole page cache-able, but there are often certain parts of that page that you want to be cached. The best way to go about it would be separate the parts that can from those that can't and put them in separate view files. Then why not make anything and everything cache-able and allow the user of the framework to limit out what shouldn't be cached? It's a far easier way to go about it without any flaws except for those between the monitor and the seat.

[448191]

That doesn't really help...

 

Maybe some code helps to illustrate what I'm struggling with.

 

This is the top part of my controller map. It's just an example implementation.

 

<?xml version="1.0"?>
<!DOCTYPE controller_map PUBLIC "Backbone Application Controller Map" "controller.dtd">
<controller_map>
<view lifetime="216000">index.php</view>
<forward status="INTRUSION_ERROR" context="Security" command="RegisterIntrusionAttempt"/>
<forward status="UNKOWN_ERROR" context="ApplicationError" command="ShowError"/>
<context id="Security">
	<command name="RegisterIntrusionAttempt">
		<view>intrusion.php</view>
	</command>
</context>
<context id="ApplicationError">
	<command name="ShowError">
		<view_update target="contentContainer">application_error.php</view_update>
	</command>	
</context>
<context id="Index">
	<view_update target="contentContainer" lifetime="7200">news.php</view_update>
	<view_update target="enableModJs">js/modjs.php</view_update>
	<command name="Index"/>	
</context>

 

As you can see, the base view and view updates have 'lifetime' attributes. These are parts of the template that I (acting as client developer) deem cacheable.

 

Right now however, caching is done very late in execution, namely when assembling the view:

 

public function getEvaluatedContents($filePath, $lifetime = 0){
	if($this->enableViewUpdateCache && $lifetime){
		//Try getting from cache:
		$cache = Backbone_Cache::factory('view');
		if($str = $cache->get($filePath)){
			return $str;
		}
			else {
			$ob = $this->obGet($filePath);
			$cache->set($filePath, $ob, $lifetime);
			return $ob;
		}
	}
		else {
		return $this->obGet($filePath);
	}

}

 

Contexts and Commands are still executed, creating unnecessary execution time as well as possible misrepresentation of the view. I somehow have to bind the generated html to a set of commands executed (without affecting non cacheable parts) AND reproduce the state of the application that it would normally be in when these commands were executed.

 

Come to think of it (talking to myself often helps  ), I COULD have the Application Controller handle the caching of the Domain Model (reproduce the sate of a transaction) and at the same time associate a cache of generated html... That might work, I'll think about that. It would still mean the dispatching cycle is fully executed though, but that is probably necessary.

 

I would still like to be able to cache a whole view though. I can think of plenty of cases when it is appropriate. You are right to say that I should leave that to the client developer though. I'm thinking something like:

 

<request lifetime="216000" static="true">/Article/Read/*</request>

 

Where the 'static' attribute would indicate if the Domain Model should be reproduced, or not, as in this case.

 

The client developer would have to make sure that this rule doesn't apply when not the whole view is cacheable. For example, when a user is logged in, the request url could look like something like this instead:

 

/User/Article/Read/id/56

 

Another thing, I'm thinking about integration of Object caching into the Registry. Basically that would be the Application Registry, which was in my original plans. When using file system based caching, that would work without issues, but I've also implemented Memcached functionality, and that has me a bit twisted.

 

Anything that can be satisfied from the in-memory Registry doesn't have to go over the network as that would introduce overhead. So how do I avoid double copies of data in memory (in PHP and and the Memcached server)? I don't think I can.

[Eric_Ryk]

I don't know exactly how you have your application set-up, but you should have something that is responsible for calling upon the controller/action/whatever you call it and gathers the view from it. All you'd have to do is a quick check to see if that controller/action/whatever's view has been cached, and fill that in as the view instead.