I often use this when implementing a simple login screen for a password protected section of my application. In a Zend Framework application you can implement a preDispatch() function in a Zend_Controller_Action which will run before an action is dispatched. This lets you setup your filter to check to see if the visitor is logged in or not. If the visitor is not logged in, you can redirect them to the login screen of your application.

Setting Up Exceptions For preDispatch

If your login screen is managed by a different controller, the setup described above is fine. If, however, your login screen is managed by an action in the same controller as the protected actions, you will want to allow unauthenticated access to the login screen. To do this, we need to exclude certain actions from the authentication check. Ruby on Rails let’s you define :except => :actionName to allow certain actions to skip the before_filter. With the Zend Framework, we have to implement that functionality on our own… but it’s easy.

What Action Is Being Called?

To set up your preDispatch function to skip checking to see if a user is logged in for certain actions you need to know which action is being called. You do that like this…

$action = $this->_request->getActionName();

Example Code

Now all you have to do is see if the action that is being called is one of the actions that you want to skip. I set up a private function called verify() to check whether or not the visitor is logged in. If the user is not logged in, I forward them to the loginAction() function. Since an unauthenticated user needs to be able to access the login screeen, we tell the preDispatch() function not to verify visitors requesting the login action. My controller ends up looking someting like this.

class AccountController extends Zend_Controller_Action {

  function preDispatch() {
    // Discover what action is being requested
    $action = $this->_request->getActionName();

    // Create a list of actions which allow unauthenticated access
    $exclusions = array("login");
    if(!in_array($action, $exclusions)) {
      $this->verify();
    }
  }

  /**
   * Check to see if the visitor is logged in. If not, send to loginAction
  */
  private function verifty() {
    $auth = Zend_Auth::getInstance();
    if(!$auth->hasIdentity()) {
      $this->_forward("login");
    }
  }

  function loginAction() {
    // Display your login screen
  }

  // Continue the rest of your class...
}

A while back I wrote about using Ruby on Rails to develop noise reduction headphones. Tonight, we made the move to the Zend Framework. We did this for a variety of reasons including the fact that we are now hosting our site on a dedicated server with RackSpace. RackSpace is the absolute best hosting company on the planet provided you can afford their rates. RackSpace does not “officially” support Ruby on Rails. This was one of the significant factors in choosing the Zend Framework. Check back soon and I will have a fairly comprehensive comparison of our experience in developing an ecommerce website with the PHP Zend Framework versus our experience building the exact same site with Ruby on Rails.

In the meantime, we have two new products on the website. By popular demand, we now have an amazing set of speakerless noise reduction headphones. We also have a great budget set of noise canceling headphones that are smaller than our premier EX-29 Extreme Isolation Headphones. This makes them great for travel!

I have been writing several Zend_View_Helpers to aid in the development of my Zend Framework Application. The helpers are very generic and are used in many of my Views throught my applications. So, naturally, I want an easy way to configure my Views to have access to my custom View Helpers. You don’t want to override the init() function in ALL of your controllers to set the View Helper path. Instead, set it in the bootstrap file – your index.php file in the root directory of your website. You do it like this:

$view = new Zend_View();
$view->addHelperPath("DU/View/Helper", "DU_View_Helper");
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer->setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);

Put those lines of code in your index.php file somewhere before you call dispatch() on your front controller and all of you view scripts will have access to your own library of View Helpers.

My company’s name is Digital Underware so I have my library set up just like the Zend library in the lib directory of my application. The path to my View Helpers is lib/DU/View/Helper just like the path to the built-in Zend View Helpers is lib/Zend/View/Helper.

If you are interested in seeing a complete example, take a look at this bootstrap file.

I was trying out a plugin in my Ruby on Rails application and decided not to use it. Apparently, when I installed the plugin, a reference to it was added to my subversion repository. Since the reference was not to a working directory, my capistrano deployments got debackled and died. Here is how you can remove external repositories from subversion.

If you get a message like this one when you are working with subversion:

Fetching external item into 'vendor/plugins/...'

Change directories so that you are in the root of your Rails application and issue the following command:

svn propedit svn:externals vendor/plugins

A list of the external plugins will appear in your default editor. Mine is vim. Delete the link that you no longer want, save the file and commit your changes.