How using requestAction increased performance on my site

who knew

I love requestAction – In the admin areas of a site it’s sometimes useful to have the hasMany records visible on the edit screen of the main model. E.g. Post hasMany Comments – when you edit Post, you get the index view of comments under it (actually I have JS tabs that separate the post edit form from the comments index).

I use requestAction to get the “baked” rendered index view of comments for that post, which are paginated, then use Ajax pagination to page through the result set, all the while staying on the edit Post screen.

I use the approach of requestAction to initially load a bare view, then update the view with Ajax in quite a few other places as well – mainly just in the admin sections where performance is not critical, but hey, now I’ve seen this, using it in the main site may not be such a bad idea either.

Good post Mark, nice one, thanks for dispelling the myths.

Nice article.

I am relativly new to cake. So I have a question. Why in the first place did you think “requestAction was evil”?

@Akif: In /cake/libs/object.php you find the requestAction-function. It creates a new instance of the dispatcher which then processes the supplied argument (e.g. ‘/posts/show/15’). Your app has to create new instances for all needed classes (including models, helper etc.) and render the view which then gets passed back to your original call to requestAction().

The additional request blocks the first one.

This makes it slow and inefficient – in some cases, as you can see :)

Actually, this makes me wonder what’s going on behind the scenes with
$this->Sidebox->addBox(‘recentPosts’, $recentPosts, $options);
if a refactoring to requestAction manages to yield a 160% increase …

Could it be that using requestAction inderectly allows you to render a cached view ?

Agreed, and thanks for the feedback :)

I agree completely that the caching is what’s yielding the performance improvement here.

I’ve also gotten tired of the “going around your elbow to get to your…” (well you know), approach required for dynamic elements on a page like your sidebar pieces.

What I found though, was that the code itself was really straightforward it was the over-the-top adherence to the architecture that made it a pain.

A simple:

$news = ClassRegistry::init(‘News’);

and suddenly the helper can grab the latest articles.

Adding Cache::read() and Cache::write() at the beginning and end respectively and we’re golden.

Goes well with the fat model structure too.

Taking a page from the FormHelper, I found that Helpers become extremely powerful for this sort of thing when you just use the class registry to access the model directly.

Can you post the sidebox helper. It would be great for me as a begginer.

I avoid requestAction when I can, but use it sometimes (not as much as I cache).

I’m actually running into a requestAction problem, when from from a model (which is accessed directly from a shell) it’s not initializing helpers on the controller. // researching still, but if you’re familiar, let me know.

ignore my previous comment about helpers not initializing, stupid user error on my part.

as penance, here’s a helper method which does requestAction caching:

	/**
	* A simple helpful tool to get any request action as a cached element
	* @param string $actionPath
	* @param string $cacheEngine
	* @return string $requestActionResponse
	*/
	function cachedRequestAction($actionPath, $cacheEngine='default') {
		$cacheKey = 'helper_cached_request_action_'.md5(serialize($actionPath));
		if (($data = Cache::read($cacheKey, $cacheEngine)) === false) {
			$data = $this->requestAction($actionPath, array('return' => true));
			Cache::write($cacheKey, $data, $cacheEngine);
		}
		return $data; 
	}

is there any reason why requestAction doesn’t take into account $cacheAction ?