Here is the basic skeleton of the new feed controller:

class FeedController extends Zend_Controller_Action
{
  public function digestAction()
  {
    // TODO: Insert digest action handling code here
  }
 
  // TODO: Insert any additional member functions here
}

The controller contains one action handler, for the digest action.

The implementation of the action handler starts by disabling the standard layout, as it is an AJAX request:

    $this->_helper->layout->disableLayout();

It then tries to get the blog ID. If it cannot, it reports an error; if it can, it then tries to fetch the digest for the log.

    // Get the blog ID
    $id = $this->getRequest()->getParam('id');
 
    if (isset($id))
    {
      try
      {
        // TODO: Insert code to fetch blog digest and pass it to the view here
      }
      catch (Exception $e)
      {
        // Log the error
        $log = $this->getInvokeArg('bootstrap')->getResource('log');
        $log->err('Error retrieving feed - ' . $e->getMessage());
 
        // Report the error
        $this->view->errorMessage = 'Error retrieving feed';
      }
    }
    else
    {
      $this->view->errorMessage = 'Blog ID not specified';
    }

Note that the process of fetching the digest is wrapped in a try/catch block to handle any errors; these are logged in detail.

Now we go through a two stage process:

1. First we check whether the digest for the specified blog ID is in the cache; if it is, we use that
2. However, if it it not, we retrieve the feed URL from the database, then fetch the digest from the feed

In both cases, either the digest is passed to the view script, or an error message, should an error occur.

The implementation of this is given below.

        // See if we can get the feed info from the cache
        $cache = $this->_getCache();
 
        if (!$this->view->digest = $cache->load('feed_' . $id))
        {
          // Get the blog information from the database
          $dbTableBlog = new Application_Model_DbTable_Blog();
          $select = $dbTableBlog->select()->where('id = ?', $id);
          $row = $dbTableBlog->fetchRow($select);
 
          if (isset($row))
          {
            // Get the blog digest from the feed and cache it
            $this->view->digest = $this->view->feedDigest($row['feed']);
            $cache->save($this->view->digest, 'feed_' . $id);
          }
          else
          {
            $this->view->errorMessage = 'Blog ID not found in database';
          }
        }

The cache object is created by a call to the following private member function of the controller’s class:

  private function _getCache()
  {
    // Set the cache frontend and backend options
    $frontendOptions = array(
      'lifetime' => 7200, // Cache lifetime of 2 hours
      'automatic_serialization' => true
    );
 
    $backendOptions = array(
      'cache_dir' => APPLICATION_PATH . '/cache/' 
        // Directory where to put the cache files
    );
 
    // Get a Zend_Cache_Core object
    $cache = Zend_Cache::factory('Core', 'File', 
      $frontendOptions, $backendOptions);
 
    return $cache;
  }

Note that we need to configure a front end and back end for the cache. The former is concerned with things like the lifetime of the cache, the latter with where the cached data is stored.

The view script is as follows:

<?php
if (isset($this->errorMessage))
{
  if (APPLICATION_ENV == 'development')
  {
    printf('<p class="error">%s</p>', $this->errorMessage);
  }
  else
  {
    echo '<p>No posts found</p>' . PHP_EOL;
  }
}
else
{
  if (strlen($this->digest) > 0)
  {
    echo $this->digest . PHP_EOL;
  }
  else
  {
    echo '<p>No posts found</p>' . PHP_EOL;
  }
}

Note that the script is set to render a more descriptive error message in development mode, to assist with debugging. Otherwise, the script should be self-explanatory.

Some of the more recent articles I have written have already touched on some of the things I have been adding to the site; see the post on pagination, the post on a plugin to populate the registry and the post on automatically generating a sitemap. I intend to do some further posts on the new parts of the site implementation that are of wider interest.

First, we need to create the controller class used to field the request for the sitemap. This is called SitemapController and is located in controllers/SitemapController.php. The class has the following skeleton:

class SitemapController extends Zend_Controller_Action
{
  // TODO: Implement the class action handlers here
}

The first action is the index action, which is handled by the follow method of the class:

public function indexAction()
{
  $this->_helper->layout->disableLayout();
}

This disable the standard layout, so that only the XML of the sitemap is rendered.

The accompanying view script file is application/views/scripts/sitemap/index.phtml and contains the following code:

<?php
$this->navigation()->sitemap()->setFormatOutput(true); 
echo $this->navigation()->sitemap();

This takes the pages in the navigator and uses them to generate a sitemap.

Now, if you navigate to http://[your-domain]/sitemap, the sitemap will be rendered in the browser.

Now we need to set up the router, so that a request for http://[your-domain]/sitemap.xml also brings up the sitemap.

To do this, we should add the route to the application configuration file:

resources.router.routes.sitemap.type = "Zend_Controller_Router_Route_Static"
resources.router.routes.sitemap.route = "sitemap.xml"
resources.router.routes.sitemap.defaults.controller = "sitemap"
resources.router.routes.sitemap.defaults.action = "redirect"

We now need to add another action handler to the SitemapController class:

public function redirectAction()
{
  $this->_redirect('/sitemap');
}

The reason for doing this indirect redirection is that if we route directly to sitemap/index, the navigator becomes confused and renders all the URLs in the sitemap incorrectly. You can confirm this by changing the ini file setting above from “redirect” to “index”.

First we need a line like this in the configuration file to allow the bootstrapper to find our plugin:

pluginPaths.Application_Resource = APPLICATION_PATH "/resources"

The key Application_Resource indicates the prefix given to the class that implements the plugin, minus its trailing underscore. The value indicates the location in which the plugins with this prefix are stored.

The class itself is implemented in Registry.php in the resources directory. It contains the following code:

<?php
class Application_Resource_Registry 
  extends Zend_Application_Resource_ResourceAbstract
{
  public function init()
  {
    // Get the registry object
    $registry = Zend_Registry::getInstance();
 
    // Get the options that should be placed in the registry
    $options = $this->getOptions();
 
    // Add the options to the registry
    foreach ($options as $index => $value)
    {
      $registry->set($index, $value);
    }
 
    return $registry;
  }
}

The code should be fairly self-explanatory. The options are key/value pairs retrieved from the configuration file, e.g.

resources.registry.phone = "phone number"

In the above case, the value “phone number” is stored under the index phone in the registry.

Books or articles about PHP or JavaScript have usually been pitched at the novice programmer; this is fine if you are a novice programmer, but as someone with considerable experience of C++ and other such languages, I don’t fall into that category. As a result, I find these works tend to finish at the point where I’d like them to begin! For me, the chief merit of Practical Web 2.0 Applications with PHP by Quentin Zervaas is that it is pitched at a higher level, and therefore addresses the sort of topics that I am more interested in.

The book looks at the development of a complete Web 2.0 application. The thing that first drew me to the book was that it used the Zend Framework, which I was in the process of learning at the time. It uses Zend Framework 1.0 in its examples, so there are plenty of modules that have been added to subsequent versions of the framework that the author might have used in his examples, but obviously couldn’t. Undoubtably the most useful thing I learnt was how to use Zend Controller plugins to perform such tasks as checking whether a user is logged in.

The book somewhat eccentrically uses Smarty for rendering its view scripts rather than the built in Zend Framework mechanism. I have not tried this out in practice, since I am happy enough with the existing facilities, especially following the introduction of modules such as Zend_Layout and Zend_Paginator. However, the examples work fine and may be of interest, either because you have a preference for using Smarty, or because you have some exisiting Smarty templates you wish to reuse within the Zend Framework.

The author includes some of his own classes that he uses to manage database access. These are built on top of the existing Zend Framework databases classes. They represent a decent approach to handling databases read/write operations in a clean fashion.

The JavaScript in the book uses the Prototype/Scriptaculous libraries. The specific usefulness of these examples will be determined by whether you use these libraries, but the general approach to using JavaScript is of wider relevance.

Overall, I found this a very helpful book. There were some things in it that were of direct use, but just as importantly, it was a stimulating look at developing a complex web application from a higher level.

Let us assume that we are adding our password and password repeat fields in the init method of our form class, which is derived from Zend_Form:

    $this->addElement(
      'password', 'password', array(
        'label'      => 'Password:',
        'maxLength'    => 64,
        'required'    => true,
        'decorators'  => $this->getFieldDecorators(),
        'errorMessages'  => array('Please enter a password')
      )
    );
 
    $this->addElement(
      'password', 'repeat_password', array(
        'label'      => 'Repeat Password:',
        'maxLength'    => 64,
        'required'    => true,
        'decorators'  => $this->getFieldDecorators(),
        'errorMessages'  => array('Please repeat the password correctly')
      )
    );

Note that both fields have the required option set to true; this is necessary event in the case of the repeat_password field, where we will be adding another validator later on. Also note that we have specified custom error messages for both fields, since the default messages are not appropriate.

The second and final step is to override the isValid method of the form class, and add the validator there:

  public function isValid($data)
  {
    $this->getElement('repeat_password')->
      addValidator(new Zend_Validate_Identical($data['password']));
 
    return parent::isValid($data);
  }

It is necessary to do it at this point, since it is only then that we have access to the value of the password field.

The form will now fail to validate if the password is not repeated correctly, and the appropriate error message will be generated.

Zend_Paginator works as follows:

1. The paginator is passed either an actual set of data, or a database query that can be used to retrieve the data.
2. The paginator will by default retrieve the first page and 10 items on that page; the page and the items per page can be set at this point if necessary.
3. The paginator can be used to render a navigator, by retrieving the current page and the number of pages.
4. The paginator can be used to render the current page, by iterating over the paginator to retrieve each item in order.

I shall give a concrete example of how this can be implemented below, based on an application I am currently developing.

First, let us start with the controller. In this instance, the controller is user and the action is index. The skeleton for this code is as follows:

class UserController extends Zend_Controller_Action
{
  public function indexAction()
  {
    // Insert implementation here
  }
}

The current page will be passed via the URL as a parameter. The first task in the action handler is therefore to retrieve the page number. If it is not specified, it will default to 1.

    // Get the current page
    $page = $this->getRequest()->getParam('page', 1);

The next step is to construct a Zend_Db_Select object that represents the database query. To do this we need a database adapter; below, we assume that this has been created during the bootstrapping process and can be retrieved via the bootstrap object. The query simply retrieves all records from the user table, ordering them by the user’s display name.

    // Get the boostrap object
    $bootstrap = $this->getInvokeArg('bootstrap');
 
    // Get the database adapter
    $dbAdapter = $bootstrap->getResource('db');
 
    // Create the selection object
    $select = $dbAdapter->select()->from('user')->order('name');

Now we have the select object, we can use it to create the paginator object.

    // Get a Paginator object using Zend_Paginator's built-in factory
    $paginator = Zend_Paginator::factory($select);

We can then set the number of items per page and the current page.

    // Set the number of items to show per page
    $paginator->setItemCountPerPage(5);
 
    // Select the requested page
    $paginator->setCurrentPageNumber($page);

Finally, we should pass the paginator object to the view script.

    $this->view->paginator = $paginator;

The view script used is given below. Note that the application uses Zend_Layout, so only the unique content of the page needs to be generated here.

<h3>User Management</h3>
 
<?php
// Display pagination control
echo $this->paginationControl($this->paginator, 'Elastic', 'paginator.phtml');
?>
<table>
  <thead>
    <tr>
      <th width="25%">Username</th>
      <th width="25%">Role</th>
      <th width="50%">Name</th>
    </tr>
  </thead>
  <tbody>
    <?php
    // Render each item for the current page in a table row
    foreach ($this->paginator as $item)
    {
    ?>
    <tr>
      <td><?php echo $this->escape($item['username']); ?></td>
      <td><?php echo $this->escape(ucfirst($item['role'])); ?></td>
      <td><?php echo $this->escape($item['name']); ?></td>
    </tr>
    <?php
    }
    ?>
  </tbody>
</table>

The script uses the PaginationControl view helper to render the navigator. The view script for the navigator markup is specified as one of the parameters as paginator.phtml; this script is found in the /application/views/scripts directory. The following standard script is used:

<?php if ($this->pageCount): ?>
<div class="paginator">
 
<!-- First page link -->
<?php if (isset($this->previous)): ?>
  <a href="<?php echo $this->url(array('page' => $this->first)); ?>">
    First
  </a> |
<?php else: ?>
  <span class="disabled">First</span> |
<?php endif; ?>
 
<!-- Previous page link -->
<?php if (isset($this->previous)): ?>
  <a href="<?php echo $this->url(array('page' => $this->previous)); ?>">
    < Previous
  </a> |
<?php else: ?>
  <span class="disabled">< Previous</span> |
<?php endif; ?>
 
<!-- Next page link -->
<?php if (isset($this->next)): ?>
  <a href="<?php echo $this->url(array('page' => $this->next)); ?>">
    Next >
  </a> |
<?php else: ?>
  <span class="disabled">Next ></span> |
<?php endif; ?>
 
<!-- Last page link -->
<?php if (isset($this->next)): ?>
  <a href="<?php echo $this->url(array('page' => $this->last)); ?>">
    Last
  </a>
<?php else: ?>
  <span class="disabled">Last</span>
<?php endif; ?>
 
</div>
<?php endif; ?>

The section used to render the current page as a table makes use of the fact that the paginator object can be iterated over to retrieve each item on the current page in turn.

The following styling is applied to the navigator:

.paginator { padding: 5px; }

The following styling is applied to the table:

table { width: 100%; }
 
th, td { padding: 5px; }
 
th { background-color: #4E7DD1; color: #FFFFFF; }

1. The application itself needs to be stored in an appropriate location, such as C:\Websites\mysite. This will contact the application, public and library directories. The public directory may have a different name, such as htdocs, depending on the target system.
2. You need to create a virtual host with the name of the application (e.g. mysite), which points at the public directory (e.g. C:\Websites\mysite\public).
3. The framework works best when used with URL rewriting. There is a standard rewriting module on Apache, called mod_rewrite. For a long time there was no such standard extension for IIS. However, Microsoft has developed IIS URL Rewrite, which provides the necessary functionality. To make use of this, you need to download and install the extension from here.
4. Then you need to add the following web.config file to the public directory:

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
    <system.webServer>
     <rewrite>
      <rules>
       <rule name="Imported Rule 1" stopProcessing="true">
        <match url="^.*$" />
        <conditions logicalGrouping="MatchAny">
         <add input="{REQUEST_FILENAME}"
                     matchType="IsFile" pattern=""
                     ignoreCase="false" />
         <add input="{REQUEST_FILENAME}"
                     matchType="IsDirectory"
                     pattern="" ignoreCase="false" />
        </conditions>
    
        <action type="None" />
       </rule>
       <rule name="Imported Rule 2" stopProcessing="true">
        <match url="^.*$" />
        <action type="Rewrite" url="index.php" />
       </rule>
      </rules>
     </rewrite>
    </system.webServer>
   </configuration>

5. Finally, you need to set the default document for the directory to index.php.
6. Because you typically set up a virtual host as a subdirectory of the default website, e.g. http://localhost/mysite, you should make sure that you use the correct base for all the URLs in your application. To that end, you can use the Base URL view helper, which comes with the Zend Framework as standard. For instance, if your contact page is reached via a request for /contact, you can make sure that the link is given the correct prefix as follows:

   <p>Click <a href="<?php echo $this->baseUrl('/contact'); ?>">here</a> 
   to contact us.</p>

The above should ensure that the application you develop runs in the same way on IIS as it would on Apache.

The feed digest class is named Default_View_Helper_FeedDigest and stored in the /application/views/helpers directory in a file called FeedDigest.php.

The basic skeleton of the class is as follows:

class Default_View_Helper_FeedDigest extends Zend_View_Helper_Abstract
{
  public function feedDigest($uri, $maxItems = 5)
  {
    // Implementation of view helper
    ...
  }
}

The Zend Framework documentation recommends that the helper either extends the class Zend_View_Helper_Abstract or implements the interface Zend_View_Helper_Interface. This is to provide support for the setView method, which will be called to give the helper automatic access to the view object.

The class returns the HTML that should be used to render the digest. The code that fetches the digest information and turns it into an unordered HTML list is wrapped in a try/catch block; this allows any feed errors to be caught.

    try
    {
      // Fetch feed digest
      ...
    }
    catch (Exception $e)
    {
      // Feed import failed
      $html = '';
    }
 
    return $html;

The first step is to perform the feed import, using the URI supplied:

      // Import feed
      $feed = Zend_Feed::import($uri);

The next step is to check the number of elements returned; if there are none, we need to render an appropriate meesage:

      // Generate digest of feed
      if ($feed->count() > 0)
      {
        // Render contents of feed
        ..
      }
      else
      {
        $html = '';
      }

If there are feed entries, these need to be converted into a list of links, with the appropriate URL and text; the number of entries returned is limited by the $maxItems parameter passed to the helper:

        $items = array();
        $count = 0;
 
        foreach ($feed as $item)
        {
          // Add the item to the list
          $pubDate = date('d M Y', strtotime($item->pubDate));
          $items[] = sprintf('<a href="%s" rel="nofollow">%s - %s</a>', 
            $item->link, $pubDate, $item->title);
 
          // Check whether the maximum item limit has been reached
          $count++;
 
          if ($count >= $maxItems)
          {
            break;
          }
        }

Finally the array is rendered as an unordered list:

        $html = $this->view->htmlList($items, false, null, false);

Because Zend_View_Helper_Abstract supports setView, and the helper is derived from that class, it can access other helpers via $this->view.

The second parameter passed to the HtmlList helper (false) indicates an unordered list; true would indicate an ordered list.

The fourth parameter is set to false, to indicate that the text in each array element should not be escaped; this is essential as they contain HTML links that should be rendered verbatim.

if (isset($this->errorMessage))
{
  if (APPLICATION_ENV == 'development')
  {
    printf('<p class="error">%s</p>', $this->errorMessage);
  }
  else
  {
    echo '<p><strong>Recent Posts:</strong> None found</p>' . PHP_EOL;
  }
}
else
{
  $digest = $this->feedDigest($this->blog->feed);
 
  if (strlen($digest) > 0)
  {
    echo '<p><strong>Recent Posts:</strong></p>' . PHP_EOL;
    echo  $digest . PHP_EOL;
  }
  else
  {
    echo '<p><strong>Recent Posts:</strong> None found</p>' . PHP_EOL;
  }
}

The view helper used to generate the digest will be examined in the next post.