A couple of notes:

• Automatic caching only occurs if debug is set to 0.
• The updated Model::find() function also implements Matt Curry’s version of custom find methods.
• After writing this code a few months ago, I came across another implementation of the same idea on End Your If. The two methods are pretty similar, but we came to the results independently. Must mean it’s a pretty good system.

We’re putting two methods into AppModel: find() and __getCachedResults(), a helper function. You can download the latest version of this code at my GitHub repository, or grab it from the bottom of this post.

Usage is simple:

• Whenever you want to cache a Model::find() result, pass ‘cache’ as one of the method’s arguments.  Pass it as either a string or an array.
  • string: the name used to generate the cache key, which takes the format: model_alias_cache_key
  • array: two valid arguments: ‘name’, used as above, and ‘config’, optionally used to pass the name of the cache config to use. ‘default’ is used if not otherwise specified.
• And that’s it! Enjoy the speed benefits, but use caching carefully. Pay attention to your cache results; only cache stuff that makes sense (for example, only cache user-specific stuff if you specify the user ID in the cache name).

The code:

<?php
class AppModel extends Model {
/**
   * Adds support for custom find methods (__findXX) and automatic caching.
   * Automatic caching will kick in when 'cache' is passed in the $options
   * array.
   *
   * If 'cache' is a string, then it will be used to generate the
   * cache name, which takes the format model_alias_cache_name.
   *
   * If 'cache' is an array, then two arguments are valid: 'name', required,
   * and 'config', optional. 'name' is used as above, while 'config'
   * determines the cache configuration to use - 'default' if not specified.
   */
  function find($type, $options = array()) {
      $results = $this->_getCachedResults($options);
      if (!$results) {
          $method = null;
          if (is_string($type)) {
              $method = sprintf('__find%s', Inflector::camelize($type));
          }

          if ($method && method_exists($this, $method)) {
              $results = $this->{$method}($options);
          } else {
              $args = func_get_args();
              $results = call_user_func_array(array('parent', 'find'), $args);
          }
          if ($this->useCache) {
              Cache::write($this->cacheName, $results, $this->cacheConfig);
          }
      }

      return $results;
  }

  function _getCachedResults($options) {
      $this->useCache = true;
      if (Configure::read('debug') > 0 || !is_array($options) || !isset($options['cache']) || $options['cache'] == false) {
          $this->useCache = false;
          return false;
      }

      if (is_string($options['cache'])) {
          $this->cacheName = $this->alias . '_' . $options['cache'];
      } else {
          if (!isset($options['cache']['name'])) {
              return false;
          }
          $this->cacheName = $this->alias . '_' . $options['cache']['name'];
          $this->cacheConfig = isset($options['cache']['config']) ? $options['cache']['config'] : 'default';
      }

      $results = Cache::read($this->cacheName, $this->cacheConfig);

      return $results;
  }
}
?>

If you find yourself paginating a lot of results, you may want to give your users the ability to change the number of results per page they see. Easy enough, I know, but the user’s preference should also persist through the session no matter what data the application is serving up. And, ideally, we don’t want to POST every time we want to change the pagination limit; I like having it right in the URL for easy reading.

So here’s a component that shows how easy it is to put in user-modifiable, session-persisting pagination limits.

The full component (app/controllers/components/auto_paginate.php):

<?php
/**
 * Auto Paginate Component class.
 *
 * A simple extension for paginating that helps with persisting user-defined pagination limits.
 *
 * @filesource
 * @author			Jamie Nay
 * @copyright       Jamie Nay
 * @license			http://www.opensource.org/licenses/mit-license.php The MIT License
 * @link            http://jamienay.com/code/auto-paginate-component
 */
class AutoPaginateComponent extends Object {

 /**
 * Other components needed by this component
 *
 * @access public
 * @var array
 */
 public $components = array('Session');

 /**
 * component settings
 *
 * @access public
 * @var array
 */
 public $settings = array();

 /**
 * Default values for settings.
 * - options: the results-per-page options to present to the user.
 *
 * @access private
 * @var array
 */
 private $__defaults = array(
 'options' => array(1, 5, 10, 25, 50, 100),
 'defaultLimit' => 25
 );

 /**
 * Configuration method.
 *
 * @access public
 * @param object $model
 * @param array $settings
 */
 public function initialize(&$controller, $settings = array()) {
 $this->settings = array_merge($this->__defaults, $settings);
 $this->controller =& $controller;
 }

 /**
 * beforeRender()
 *
 * Set the variables needed by the controller.
 *
 * @access public
 * @param $controller Controller object
 */
 public function beforeRender(&$controller) {
 $controller->set('paginationOptions', $this->settings['options']);
 $controller->set('paginationLimit', $this->paginationLimit());
 }

 /**
 *
 * Set the controller's $paginate variable.
 *
 * @access public
 * @param array $options
 */
 public function setPaginate($options = array()) {
 $defaults = array(
 'limit' => $this->paginationLimit()
 );

 $this->controller->paginate = array_merge($defaults, $options);
 }

 /**
 * Set the pagination limit based on user input and session variables.
 *
 * @access public
 */
 public function paginationLimit() {
 if (isset($this->controller->params['named']['Paginate'])) {
 $this->Session->write('Pagination.limit', $this->controller->params['named']['Paginate']);
 }

 return ($this->Session->check('Pagination.limit') ? $this->Session->read('Pagination.limit') :
 $this->settings['defaultLimit']);
 }

}

?>

Two config options: ‘options’, which determines the available results-per-page options for the user, and ‘defaultLimit’, which, predictably, determines the default pagination results limit.

To use the component, just plug it into your AppController’s $components array (app/app_controller.php):

var $components = array('AutoPaginate');

Now we need to change the way we configure pagination in individual controllers. This is the easy part – just call AutoPaginate::setPaginate() instead of explicitly defining $this->paginate when setting up your pagination. For example, in our PlayersController::admin_index() function we’re used to doing this:

$this->paginate = array(
 'limit' => 20,
 'contain' => array('Player, 'Position')
);
$this->set('players', $this->paginate());

But now we’ll just do this (app/controllers/players_controller.php):

function admin_index() {
 $this->AugoPaginate->setPaginate(array(
 'contain' => array('Team', 'Position')
 ));

 $this->set('players', $this->paginate());
}

Finally, since our pagination will be standardized through the entire site, we’ll set up a couple of common view elements.

The top element will present the choices for the number of results per page, as well as the usual “display X out of X results” line. It looks like this (app/views/elements/pagination/top.ctp):

 Results per page:
 <?php
 $results = array();
 foreach ((array)$paginationOptions as $option) {
 if ($paginationLimit == $option) {
 $results[] = $option;
 } else {
 $args = $this->passedArgs;
 $args['Paginate'] = $option;
 $results[] = $html->link($option, $args);
 }
 }
 echo implode(" | ", $results);
 ?>

<?php
echo $paginator->counter(array(
'format' => __('Page %page% of %pages%, showing %current% records out of %count% total, starting on record %start%, ending on %end%.', true)
));
?>

That’ll produce a string of plain text links – not a form – that the user can use to change pagination limits. The output looks like this:

Results per page: 1 | 5 | 10 | 25 | 50 | 100

Page 1 of 105, showing 10 records out of 1042 total... (etc)

$paginationOptions and $paginationLimit are set in AutoPaginateComponent.

We’ll also make a new element for the bottom of paginated results too (app/views/elements/pagination/bottom.ctp):

<div class="paging">
 <?php echo $paginator->prev('<< '.__('previous', true), array('url' => $this->passedArgs), null, array('class'=>'disabled'));?>
 | 	<?php echo $paginator->numbers(array('url' => $this->passedArgs));?>
 <?php echo $paginator->next(__('next', true).' >>', array('url' => $this->passedArgs), null, array('class'=>'disabled'));?></div>

Now to insert the elements into a typical view with typical paginated results. I like to insert top.ctp as a table caption, but you can do anything you’d like. If we’re paginating in, say, PlayersController::admin_index, it might look something like this (app/views/players/admin_index.ctp):

<h2><?php __('Players');?></h2>
<table cellpadding="0" cellspacing="0" class="table_list">
 <caption>
 <?php echo $this->element('pagination/top'); ?>
 </caption>
 .... (data in table) ...</table>
<?php echo $this->element('pagination/bottom'); ?>

Pretty simple, eh? I prefer using helper functions to set variables anyway, so this kills two birds in one stone by automatically setting the pagination limit and getting rid of the “$this->paginate =” business in controllers.

As always, comments, suggestions, improvements and helpful criticisms welcome!

So, I’m just going to do a little quickie here to show you how easy it is to put in user-modifiable pagination limits. We’ll write a common view element for pagination, then we’ll turn to AppController and write a couple of functions to handle setting the pagination limit and interpreting changes to that limit. Finally, we’ll slightly modify the way we set up pagination in individual controllers to handle the new code. It’ll go something like this:

• Setting up Common View Elements
• New Functions in AppController
• Modifying Individual Controller Pagination Calls

Setting up a Common View Element

OK, so if all of our paginated results are going to look the same then we might as well have a common view element. This element will present the choices for the number of results per page, as well as the usual “display X out of X results” line. It looks like this (app/views/elements/pagination/top.ctp):

 Results per page:
 <?php
 $results = array();
 foreach ((array)$paginationOptions as $option) {
 if ($paginationLimit == $option) {
 $results[] = $option;
 } else {
 $args = $this->passedArgs;
 $args['Paginate'] = $option;
 $results[] = $htmla->link($option, $args);
 }
 }
 echo implode(" | ", $results);
 ?>

<?php
echo $paginator->counter(array(
'format' => __('Page %page% of %pages%, showing %current% records out of %count% total, starting on record %start%, ending on %end%.', true)
));
?>

That’ll produce a string of plain text links – not a form – that the user can use to change pagination limits. The output looks like this:

Results per page: 1 | 5 | 10 | 25 | 50 | 100

Page 1 of 105, showing 10 records out of 1042 total... (etc)

There are two variables in the pagination/top.ctp that we need to define, as well – $paginationOptions and $paginationLimit. You just need to set these somewhere in your AppController before the view is rendered, so in, say, beforeFilter() – I actually set mine in conjunction with my quick and dirty widget component (/end shameless plug ):

// Pagination options
$this->set('paginationOptions', array(1, 5, 10, 25, 50, 100));
$this->set('paginationLimit', $this->_paginationLimit());

We’ll write the _paginationLimit() function in the next section.

We’ll also make a new element for the bottom of paginated results too (app/views/elements/pagination/bottom.ctp):

<div class="paging">
 <?php echo $paginator->prev('<< '.__('previous', true), array('url' => $this->passedArgs), null, array('class'=>'disabled'));?>
 | 	<?php echo $paginator->numbers(array('url' => $this->passedArgs));?>
 <?php echo $paginator->next(__('next', true).' >>', array('url' => $this->passedArgs), null, array('class'=>'disabled'));?></div>

Now to insert the elements into a typical view with typical paginated results. I like to insert top.ctp as a table caption, but you can do anything you’d like. If we’re paginating in, say, PlayersController::admin_index, it might look something like this (app/views/players/admin_index.ctp):

<h2><?php __('Players');?></h2>
<table cellpadding="0" cellspacing="0" class="table_list">
 <caption>
 <?php echo $this->element('pagination/top'); ?>
 </caption>
 .... (data in table) ...</table>
<?php echo $this->element('pagination/bottom'); ?>

The views are finished – now we just need the methods to make it all work.

New Functions in AppController

Two new functions here, one that we’ll use in the individual controllers in place of defining $this->paginate, and another one called by that function to set the pagination limit depending on possible user input and the existing session-written value.

The first method, _setPaginate(), is just a shortcut for setting $this->paginate in controllers, so we don’t need to set the limit every time. It’s short and sweet (app/app_controller.php):

protected function _setPaginate($options = array()) {
 $defaults = array(
 'limit' => $this->_paginationLimit()
 );

 $this->paginate = array_merge($defaults, $options);
}

Notice that _setPaginate() calls _paginationLimit(), which is the function that sets and gets the limit in the user’s session:

protected function _paginationLimit() {
 if (isset($this->params['named']['Paginate'])) {
 $this->Session->write('Pagination.limit', $this->params['named']['Paginate']);
 }

 // On two lines for blog readability.
 return ($this->Session->check('Pagination.limit') ? $this->Session->read('Pagination.limit') :
 Configure::read('SiteSettings.default_pagination_limit'));
}

The system is done – now we just have to use it!

Modifying Individual Controller Pagination Calls

This is the easy part – just call _setPaginate() instead of explicitly defining $this->paginate when setting up your pagination. For example, in our PlayersController::admin_index() function we’re used to doing this:

$this->paginate = array(
 'limit' => 20,
 'contain' => array('Player, 'Position')
);
$this->set('players', $this->paginate());

But now we’ll just do this (app/controllers/players_controller.php):

function admin_index() {
 $this->_setPaginate(array(
 'contain' => array('Team', 'Position')
 ));

 $this->set('players', $this->paginate());
}

Pretty simple, eh? I prefer using helper functions to set variables anyway, so this kills two birds in one stone by automatically setting the pagination limit and getting rid of the “$this->paginate =” business in controllers.

As always, comments, suggestions, improvements and helpful criticisms welcome!

To be fair, yours isn’t the only one that sucks – all splash pages (enter gross generalization here) suck. The internet is about content, and splash pages, especially those containing the ubiquitous and oh-so-irrelevant ‘Flash introduction’.

The more clicking a user has to do to get to the content he’s looking for (or the content you want him to find), the less likely he is to actually get there. If I’m shopping for an item and I can buy it at two stores, but one of the stores has three doors blocking the item and the other store has no doors at all, which store am I likely to enter? Common sense would dictate that I would enter the store that’s easier to navigate and has less barriers between me and the content I want.

So why, then, are Flash splash pages so popular? The number of ‘professional’ websites that have useless splash pages – often in a slow-loading medium such as Flash – astounds me. Clients usually ask for splash pages because it gives them a chance to show off, either that they have a big budget or that they like to be f(F)lashy. But what these clients don’t realize is that a splash page can often trip up search engine spider bots, since it represents a barrier between the spider and the real content. The worst case scenario is that the spider will index only the splash page, leaving your content in the dark.

Splash pages are usually self-indulgent and extraneous. Moreover, those who push for their inclusion on a website usually don’t understand the internet as a medium. Flash/splash advocates usually have too much money and not enough brains, so they just throw a whole bunch of cash at a company because they want something that looks ‘cool’ or ‘flashy’ or ‘impressive’ or whatever; usability and content definitely are not priorities. The minority of splash pages that do have content could probably be retooled so that the content is just on the ‘main’ homepage of the website. Jared Spool, who is with User Interface at Macromedia, is quoted on MarketingSherpa.com as saying:

When we have clients who are thinking about Flash splash pages, we tell them to go to their local supermarket and bring a mime with them. Have the mime stand in front of the supermarket, and, as each customer tries to enter, do a little show that lasts two minutes, welcoming them to the supermarket and trying to explain the bread is on aisle six and milk is on sale today. (taken from SEOmoz)

Could you imagine that? I know I’d last about six seconds before either punching the mime in the face or going to a different store. And, in website terms, since you can’t usually punch site owners in the face, then you’ll probably just go somewhere else for the same information.

Jakob Nielson, who would get my vote for the President of the Internet, lists Flash – that fixture of bad splash pages – as one of the Top Ten Web Design Mistakes  of 2005 (all of which still apply today). Nielson writes that Flash intro pages are “so bad that even the most clueless Web designers won’t recommend them, even though a few (even more clueless) clients continue to request them”. Smashing Magazine has an excellent showcase of splash pages, from the very worst to the poorly designed to the not-so-intolerable-but-still-unnecessary. Anytime I come across a splash page – especially one done in Flash – I turn around and walk my virtual self out the door.

I’ll end with another golden Nielson quote from the same article as above – some advice on how to design your website so that you don’t need Flash, splash, or anything of the sort:

Flash should not be used to jazz up a page. If your content is boring, rewrite text to make it more compelling and hire a professional photographer to shoot better photos. Don’t make your pages move. It doesn’t increase users’ attention, it drives them away; most people equate animated content with useless content.

click here!

Click where? Why here? Why not there? Where else am I going to click? What am I clicking on? Where am I going? Those are just a few of the questions that links labeled “click here” raise.

The world wide web should be, in my opinion, a loosely linked repository of semantic resources. That’s the ideal situation, of course; since 99% of everything on the WWW is horrible, we’re not there yet. But we few decent developers can still try to make our websites as semantic and sensible as possible. So, while they should be obvious, links don’t need to jump out of the screen and slap the user in the face. “Click here!”? Seriously? Don’t insult a user’s intelligence. If a visitor wants to follow a link, he’ll follow the link. But, that link needs to speak for itself.

By ‘speak for itself‘, I mean that the clickable portion of text should describe to the user what’s on the other side of the click. If you want to link to a page on, say, your favourite hockey team, don’t write this:

Want to read more about the Vancouver Canucks? Click here!

As you can see, the link (“Click here!”) doesn’t actually say anything about the resource to which it is pointing. Sure, there’s an explanation beforehand. But I would argue that anything surrounding the link is irrelevant; the eye is drawn to the link itself, so that’s where the important information should be. The World Wide Web Consortium (WC3), in its article “Don’t use ‘click here’ as link text“, recommends that link text should offer an exaplanation of the page to which it links and the information it offers, even when read out of context. The W3C emphasizes that one should not focus link text around mechanics (“follow this link here”), action verbs (“click”), and so on.

Website visitors know what links are and how to recognize them without explaining the mechanics of linking in the text. Too many web developers these days don’t want to give their users any credit. The bottom line is that if a person can figure out how to turn on his computer, open his internet browser, and navigate to a website, it’s a pretty safe bet that he’ll be able to recognize properly styled links. I say ‘properly styled’ because too many website owners try to be too pretty/stylish/different when it comes to presenting links. A link should be the last spot that the user expects to have strange styling. If links are recognizable – underlined, a different colour, an obvious change on hover (larger font, etc.) – users will find and follow them. One need not make the text blinking with a scrolling marquee; an understated but clear indication of a link to another resource will do the job. And, since we’re explaining the target resource in the text of the link, we don’t need to give a silly instruction like ‘click here’ to the user. A stop sign doesn’t say “press on the brake pedal”, nor does the door to a house say “open this to enter”. If we let the link speak for itself and put it in the context of other text, it will look something like this:

The Vancouver Canucks are my all-time favourite hockey team. They have speed, grit, scoring, and defense.

One would expect to find a website about the Vancouver Canucks on the other side of this link. We don’t need to say “click”, “follow”, or even something like “more information” – for example, ‘More Information on the Vancouver Canucks‘ – since the mere existence of the link implies that we’ll be getting more information. Additionally, this link tells the visitor exactly what to expect when he decides to follow without revealing how the visitor should do it.  Remember, not everyone will be ‘clicking’ on your links, since only a mouse clicks. Users navigating with the keyboard, a touch phone, a screen reader, and so on will not be clicking anything (admittedly most users will know what ‘click’ means even if they’re not using  a mouse, but it’s still good practice not to force mechanics on your visitors).

In his excellent article “Top Ten Web Design Mistakes of 2005” (and, believe me, those mistakes still apply today), web usability and accessibility guru Jakob Nielson advises that links should

Explain what users will find at the other end of the link, and include some of the key information-carrying terms in the anchor text itself to enhance scannability and search engine optimization (SEO). Don’t use “click here” or other non-descriptive link text.

As Nielson says, since links are the most common and prominent way for resources on the web to interact with each other, making links confusing and non-intuitive “is a sure way to confuse and delay users”. Many search engine optimization (SEO) experts also recommend against using ‘click here’ since search engines (so they claim) associate webpages with the words used to link to them; vague and irrelevant linking words such as ‘click here’ will only hamper a potential visitor’s ability to find these websites when searching (see, for example, Solo Signal’s “SEO Tip: Please Don’t Click Here“).

A responsible web developer ensures that a website is as accessible, usable, and sensible as possible. Using ambiguous phrases such as “click here” reduce the usabilty of a site by obfuscating one of the web’s most important elements, the link. For more information and references, see the Wikipedia page ‘Click here’.