I’ve read up on Zend_Oauth_Consumer and how it can be used to get authorisation for interacting with twitter using oauth. All well and good, I have my access key and I can merrily post away on a user’s behalf. There’s plenty of resources out there to do this so I won’t bore people.

The next step was to allow people to return to the website, log in and modify their account. This is where I reached a slight problem. Using the code examples on websites meant that I’d have twitter asking me for access authorisation again for each login, not good. Scanning through the framework I couldn’t see anything which would allow me to just request authentication. That isn’t to say its not there, but there didn’t seem to be an authentication mechanism that could be invoked without knowing the access token already.

The alternatives were to implement a site-based log in or somehow store the user’s access token on the client (encrypted of course). Neither of these seemed like a good/suitable solution.

Having a look at the requests made by my code I knew that all that was required was to change the URL to which Zend_Oauth_Consumer redirects. It seemed the easiest way to do this was to override the authorizationUrl parameter with the authentication URL from twitter. This was done as follows:

$config = array(
'callbackUrl'    => ...callback-url...,
'siteUrl'        => 'https://twitter.com/oauth',
'consumerKey'    => ...consumer-key...,
'consumerSecret' => ...secret-key...,
);
$consumer = new Zend_Oauth_Consumer($config);

$token = $consumer->getRequestToken();
// persist the token to storage
$_SESSION['TWITTER_REQUEST_TOKEN'] = serialize($token);
$consumer->setAuthorizeUrl('https://twitter.com/oauth/authenticate');
$consumer->redirect();

On return to the application from twitter we process the response as so:

$token = $consumer->getAccessToken(
$_GET,
unserialize($_SESSION['TWITTER_REQUEST_TOKEN'])
);

echo $token->user_id . ' :: ' . $token->screen_name;

How you validate/store the authentication is up to you, but this should successfully implement a ‘sign in with twitter’ system.

If anyone knows of a more correct/more elegant solution to this I would be very much interested in hearing. There seems to be a lack of information on ‘sign in with twitter’ using PHP/Zend Framework on the internet

This is a quick post to discuss the rather simple view helper I created for rendering a Zend Framework style view file only if it exists. Generally asking the code to render a file which doesn’t exist will throw an exception. Therefore I created a wrapper for the Zend_View::render() method which determined whether the file exists and if so renders, otherwise simply returns an empty string.

Joost J. Bakker IJmuiden - http://www.flickr.com/photos/joost-ijmuiden/

Motivation

The motivation for this is that I have one controller/view/etc which shows slightly different output depending on a parameter. Some of these outputs have a related help information box defined, some do not. I didn’t want to have empty files hanging around my code just as much as I didn’t want to have try {} catch {} blocks in my view file. Therefore, I quickly created a ‘render if exists’ view helper for use in my code.

I realise that here I could have just wrapped the render method within a try{}catch{} within the view helper itself. In this case however any exceptions thrown from the rendered view would not bubble back up in the case of something going wrong.

How It Works

The view helper is created by extending Zend_View_Helper_Abstract as normally, this injected with the view upon use. The view helper is passed the view file you wish to render:

$this->renderIfExists('info-box.phtml');

Internally the object gathers the script paths from the view object and loops over them trying to find the file:

    /**
     * Check to see if a view script exists
     *
     * @return boolean
     */
    protected function _fileExists()
    {
        $paths = $this->view->getScriptPaths();
        foreach ($paths as $path) {
            if (file_exists($path . $this->_file)) {
                return true;
            }
        }
        return false;
    }

If a matching file is found it uses the standard Zend_View::render() method, otherwise it returns an empty string.

Summary

This is a very simple view helper to render a view file if it exists and simply return an empty string if not. It does not use a try{} catch{} block which would prevent any deeper exceptions being thrown from bubbling up and making themselves known. Instead it loops through the script paths defined within the view object and attempts to detect the file before trying to render it.

The full file can be found at my github repo.

Photo from http://www.flickr.com/photos/daniello/

Summary

Here I discuss the creation of a view helper for modifying HTML tags, and more specifically body tags. The created view helper allows functionality similar to the head*/inlineScript view helpers already in the standard Zend Framework view helpers, but allows the programmatic modification of tag attributes. Definitely check out the demo page and the code on github.

Motivation

The standard Zend Framework view helpers are a great set of tools for streamlining mundane view tasks and allowing for the modification/addition of scripts and header blocks (generally held in the layout) from within the view without applying ugly hacks (i.e. the head*/inlineScript view helpers).

Upon occasion I have found need to make modifications to the <body> tag, for example adding an onload, class, or style attribute etc. I also required to be able to perform this from within other view helpers. Take this following contrived example…

On website X, certain pages include standard dojo forms. These dojo forms are held within view helpers for convenience. Generally it has been decided not to include the dojo CSS classes in the body tag and only add them when necessary. There maybe several view helpers on the page that need to add their own attributes to the body tag. (I said it was contrived)

The code is available in my GIT repository @ github and the demo page.

How it works

When creating the body tag view helper I soon realised that most of the code was not specific to what I was developing so I pulled out the common functionality into an abstract class.  By concreting the  abstract class it is possible to modify any tag in the same way as the body tag discussed here making the code much more versitile.

Underneath the hood (so to speak) the code is based on that of the head* and the inlineScript view helpers. It utilises Zend_View_Helper_Placeholder_Container_Standalone to store the attributes and their values until they are required. The container itself uses Zend_Registry to store values under the key defined in the class (if you look at the unit tests I clear the registry down after each test).

The code would fit in well with the “Naked Zend_Layout and Zend_View” code I wrote about a couple of weeks ago or as part of the standard Zend Framework MVC install.

Usage

The class should be very simple to use. Firstly two entries are required within your layout script as follows:

<?php echo $this->bodyTag() ?>
<?php echo $this->bodyTag()->toString(Pro_View_Helper_AbstractTag::CLOSE) ?>

Note: You’ll need to change the class name should you move the view helper to your own library. Obviously the constant is available through the implementation (bodyTag) as well as through the abstract class.

An example of making changes to your body tag using the view helper to echo <body class=”nihilo myclass” style=”text-align-left; width: 80em”> is:

<?php
$this->bodyTag('class', 'nihilo')
    ->bodyTag('style', 'text-align: left')
    ->bodyTag('style', 'width: 80em', false, ';')
    ->bodyTag('class', 'myclass')
?>

This can be done throughout the view file, in several view helpers, and in the layout file (provided its before the body tag is written out). Attributes can be removed/overwritten whilst values can be added and appended (separator can be passed). If the same attribute value is passed several times only a single copy is written with the attribute.

For a full demo either fork the github repository and run the demo.php file in your own browser, or alternatively visit this page to see it in action. Usage of the demo.php script assumes you have the Zend Autoloader (or similar) already setup.

Creating your own Tag helper

To implement your own view helper simply extend the abstract tag class and overwrite the following class properties:

• $_regKey: A unique key for the tag (used for Zend_Registry)
• $_validAttributes: An array of valid attribute names, should be lowercase to comply with W3C
• $_selfClosing: Boolean value to specify if tag is self closing or not, e.g. <br/>
• $_tagName: Name of the tag (i.e. body in this example)

So, finally the code for the bodyTag view helper itself, its very compact:

/**
 * View helper for the body tag
 *
 * @author     Lloyd Watkin
 * @since      21/08/2010
 * @package    Pro
 * @subpackage ViewHelper
 */
class Pro_View_Helper_BodyTag
    extends Pro_View_Helper_AbstractTag
{
    /**
     * Registry key for placeholder
     *
     * @var string
     */
    protected $_regKey = 'Pro_View_Helper_BodyTag';

    /**
     * Which attributes are valid
     *
     * Currently only STF attributes supported
     * (S = STRICT, T = TRANSITIONAL, F = FRAMESET)
     *
     * @see http://www.w3schools.com/tags/tag_body.asp
     * @var array
     */
    protected $_validAttributes = array(
        /* Standard Attributes */
        'class', 'dir', 'id', 'lang', 'style', 'title', 'xml:lang',
        /* Event Attributes */
        'onclick', 'ondblclick', 'onload', 'onmousedown', 'onmousemove',
        'onmouseout', 'onmouseover', 'onmouseup', 'onkeydown', 'onkeypress',
        'onkeyup', 'onunload',
    );

    /**
     * Self closing tag?
     *
     * @var boolean
     */
    protected $_selfClosing = false;    

    /**
     * Tag name
     *
     * @var string
     */
    protected $_tagName = 'body';
}

If you take a look at the repository there’s also a group of unit tests that fully cover the functionality. The unit tests are written in PHPUnit and are in the BodyTagTest.php file.

Finally…

Here I’ve shown you my implementation of an abstract tag abstract view helper (eek) and its body tag implementation. Whilst the javaScript functionality can be implemented in other ways (other than hard coding at output time) other things can’t (without javaScript that is) without changing other parts of the application. I hope you find the classes helpful in your application…

Dependency injection is a technique that allows for loosely coupled objects within a software application. Generally if an object requires access to the functionality of another it would be instantiated internally leading to tightly coupled systems. By implementing dependency injection we inject the required objects ready for use (sometimes also referred to inversion of control – IOC). Take the following example:

<?php
class DecisionMaker {
    public function makeDecision(array $parameters) {
        // Need the database adapter
        $dp = new DecisionParameters();
        $parameterScore = $dp->getScore($parameters);
        /* ... Some more decision logic ... */
        return ($parameterScore > 50);
    }
}

This piece of code is said to be tightly coupled to the DecisionParameters object. Rewriting the above in a loosely coupled fashion we’d have something like….

<?php
class DecisionMaker {
    private $_dp;
    public function __construct($dp) {
        $this->_dp = $dp;
    }
    public function makeDecision(array $parameters) {
        $parameterScore = $this->_dp->getScore($parameters);
        /* ... Some more decision logic ... */
        return ($parameterScore > 50);
    }
}

Whilst gaining the benefits of loosely coupled code we are adding complexity such that each time an object is instantiated we also have to instantiate its dependencies and pass these in too. For example, this:

$choice = new DecisionMaker();
echo $choice->makeDecision(array('effort' => 'low', 'return' => 'high'));

now becomes:

$dp = new DecisionParameters();
$choice = new DecisionMaker($dp);
echo $choice->makeDecision(array('effort' => 'low', 'return' => 'high'));

This situation becomes more painful as the number of dependencies for a class is increased, and what if the dependencies themselves have dependencies? This can quite quickly become an object administration nightmare! Enter dependency injection containers (or frameworks)…

Dependency Injection Containers/Frameworks

Dependency injection containers (or frameworks) handle the process of object creation; instantiating and injecting any dependencies before returning an instance to the caller.

In your code rather than create new objects directly we request a copy of the object from the DI container. The object we are returned already has  all its dependencies injected and the object is ready to go.

Symfony Dependency Injection Container

Symfony is probably best known for their full stack MVC framework however they have also released a number of the components that can be used independently. For example, the dependency injection container we’re going to talk about here, a YAML parser, a templating engine, see Symfony components for more.

The Symfony DI container is based on that from the Spring Framework in Java.

Bootstrapping

In order to bootstrap the Symfony dependency injection framework we use code as included below. I have chosen to use YAML just because its easy to read and setup. For maximum speed you may want to write out your containers to plain PHP (the Symfony container can do this for you once setup), or alternatively cache the whole container using Zend_Cache, or similar.

To install Symfony DI follow the instructions included here http://components.symfony-project.org/dependency-injection/installation, and add it to your path.

// Load the Symfony DI container
require 'sfServiceContainerBuilder.php';
$container = new sfServiceContainerBuilder();
$loader = new sfServiceContainerLoaderFileYaml($container);
$loader->load(APPLICATION_PATH . '/config/di/services.yml');

Firstly we instantiate a new container, and then we load our configuration from a YAML file. Note: the DI container can load config from several formats such as XML, YAML, PHP, and INI*.  I tend to include a single YAML file and import other files from within there.

Several configuration files can be imported using different formats, the newer definitions overwriting those that have already been defined. Configuration files can include references to objects and parameters.

*INI is only able to define parameters and is unable to import other files

Configuration Example

imports:
  - { resource: daos.yml }

parameters:
  username: false

services:
  # Customer model
  model.customer:
    class:  Pro_Customer
    calls:
      - [ setLogger, [ @utils.logger ] ]
      - [ setDao, [ @data.userdata.mysql ] ]
      - [ setUserName, [ %username% ] ]

  # Product model
  model.product:
    class:  Pro_Product
    arguments: [%username%, { type: %accesslevel%, lastlogin: %lastlogin% } ]
    calls:
     - [ setDao, [ @data.product.mysql ] ]

  # Logger
  utils.logger:
    class: Pro_Logger
    constructor: getInstance
    calls:
      - [ setHandle, [ @utils.filewriter ] ]

I think the code above is fairly self explanatory but for clarity I’ll explain each part now.

First off we define some imports (i.e. other files to parse), I like to group my configurations for example DAOs in one file, utilities in another and name the file appropriately. Whilst a little slower it speeds up the maintenance of the configuration files. Its also possible to parse files of other formats using different import flags. Files are parsed in order with newer definitions overwriting or amending previously defined services/parameters.

Next we define a parameter, a parameter can generally be any PHP variable type. At this point I didn’t know what my username parameter should be (I need to authenticate for that!), so I’ve defined a default value and I’ll overwrite that value later. Note, classes aren’t instantiated until you ask for them so defining parameters a little later is perfectly fine. Following this I define some services:

1. Instantiate Pro_Customer, pass an instance of my logger to the setLogger() method, add in my MySQL data access object (DAO), and pass in the username as well. Each time I ask for this object I want a new instance
2. Create an instance of Pro_Product, pass arguments of username and an options array to the constructor. After instantiation call setDao() and pass it my product DAO
3. Give me a copy of Pro_Logger, instantiate it using the getInstance() method and pass a copy of my file writer object via setHandle() once its loaded. My file writer is defined in one of my imports.

Within the configuration files services are referenced by prepending the name with an ‘@’ symbol, parameters are referenced by prepending and appending with ‘%’ symbols, e.g. @utils.logger %username%.

Adding data post loading

Sometimes you don’t know what the value of parameters should be until after you have bootstrapped, as with our username parameter above. In order to overwrite the value the offsetSet() method is used, firstly passing the parameter name followed by its new value:

$container->offsetSet('username', $username);

Getting Objects from the container

Once setup rather than instantiating objects directly we now go to the DI container to get instances. With the Symfony DI we call the getService() method, passing in a string which describes the variable you wish to retrieve, e.g.

$logger = $container->getService('utils.logger');

This will perform the equivalent of:

$logger = Pro_Logger::getInstance();
$fileWriter = new Pro_Writer_FileWriter();
$logger->setHandler($fileWriter);

It is possible to determine if the container has an instance of a service by calling the hasService() method, which returns a boolean value.

Its not necessary to have access to the container beyond the top level of your application since once retrieving an instance all of the required dependencies right down to the deepest depths of your application are already setup and waiting to be called.

Unit Testing

Dependency injection also has the added benefit of allowing objects to be tested in isolation. Taking the DecisionMaker class example before implementing the dependency injection setup our test results were also dependent on the implementation of the DecisionParameters class.

Should the DecisionParameters class return different results our tests could start failing through no fault of our own. Using dependency injection we can now pass in a DecisionParameters object which returns a known/fixed set of results for certain input parameters, we are now testing DecisionMaker in isolation from any external factors, i.e. if our tests start failing this can be directly attributed to something changing in the DecisionMakeer class. This is particularly important should you be relying on test data from a database for testing.

Application Configuration

The way in which your application behaves on your production server will inevitably differ from your development setup. For example, in a development environment the level of logging would be much more granular than on your production system. By altering your dependency injection container configuration files slightly (or parsing an additional configuration file) the altering of behaviour depending on the environment is made simple.

By type hinting on interfaces rather than implementations when setting your dependencies its also possible to swap out components for compatible components with a few lines of YAML or XML. For instance, you may currently access your database via a MySQL DAO (Data Access Object), but in time you may develop a PDO, Zend_Db, or Doctrine implementation of this DAO. By adding the new implementation into your configuration file suddenly all the objects that used the old MySQL implementation are now using your new implementation without needing to attack the bowels of your application.

Notes

• By setting shared: true in the configuration we are always given the same instance of an object. This is very useful when dealing with objects which contain resources such as database connections, file handles, etc
• There are two methods by which dependencies can be injected. One is to pass dependencies with the constructor, or alternatively via setter methods. The generally accepted pattern is to pass required dependencies via the constructor and optionals via setters. My personal preference is to use setters for everything, but this is down to the individual developer

Finally….

Along with a brief discussion on dependency injection and its advantages and disadvantages this has also been a quick-start guide to implementing the Symfony Dependency Injection Container… hopefully you’ve seen that it’s surprisingly quick and easy. From here you’ll be able to start using dependency injection through your application and look to using many more of the advanced features (although the simple example covers the vast majority of functionality you’ll require). As always I point you to the manual for further information.

In this article I look at using Zend_Layout and Zend_View along with a simple front controller to show how it is possible to start separating business logic and presentation within your application. All code is available on github:
Naked Zend_Layout and Zend_View on GitHub.

MVC

A common design pattern for modern web applications is the MVC pattern. The Zend Framework in ‘full stack’ mode is one implementation of MVC in PHP and consists of three parts:

• Model (M)
• View (V)
• Controller (C)

The pattern is designed such that business and presentation logic are completely separated from one another (with business logic in the model, and presentation in the view) and the controller sitting in the middle conducting the “orchestra”.

Presentation and Logic

In the Zend Framework the view  is handled by two main components: Zend_View and Zend_Layout. Zend_Layout as the name suggests looks after the layout  aspect of the site (generally headers, footers, sidebars, etc). Zend_View focusses on presenting the data that your model has been working to produce or derive.

As developers, and their applications, evolve we tend to move through various stages, generally each an improvement on the previous, improving maintainability and extensibility. One of the main issues is that presentation and logic still get intermingled and its not simple to start separating the two.

What’s wrong with mixing the two?

There’s several reasons why mixing different parts of the application, for example a designer working on your site may not want to (or have the knowledge) to scan around in code trying to work out where to make presentation changes. In the same way a developer (if you’re like me who has the design skills of an ostrich) may break out in a cold sweat when you mention design or UI work.

Additionally what if later you would like to present your sites on different media, such as mobile telephones, tablet PCs, or expose the data via web services (XML/JSON/etc)? Having mixed presentation and logic you stand almost no hope without some very ugly hacks to pull the presentation back out of your code, before injecting something new. If data and presentation has been separated making these changes are almost trivial, create a new view script for the new format and direct requests as appropriate.

Separating the two

In an evolving application its not always economical to start implementing a full MVC solution and the application needs to be migrated slowly – sometimes running old code in parallel with new. It maybe that there are masses of logic (such as database connection setup, authentication, cookie handling, etc) that aren’t ready for moulding to your chosen frameworks setup, therefore old and known-to-be-working code can continue to be used until such time it can be rewritten/refactored.

Note: Using Zend_Layout and Zend_View like this is perfectly acceptable within the Zend Framework landscape and the framework has been designed such that individual components can be used without the rest of the framework. A great advantage in evolving applications and probably one of the major reasons for its high uptake in enterprise applications.

Front Controller

Below I create a front controller  - a single file designed to pick up any requests which are not matched to a file on the file-system. This is often achieved using a .htaccess file such as the one used in the default Zend Framework install. Within the front controller I will be setting up our layout and view and showing where the different parts of the application slip into it.

define('APP_PATH', dirname(__FILE__). '/..');
// Start buffering output
ob_start();

// Create a Zend_View instance
Zend_Layout::startMvc();
$layout = Zend_Layout::getMvcInstance();
$layout->setLayoutPath(APP_PATH . '/layout/scripts')
    ->setViewSuffix('phtml')
    ->setLayout('index');

$view = $layout->getView()
    ->setScriptPath(APP_PATH . '/view/scripts')
    ->addHelperPath(APP_PATH . '/library/Zend/View/Helper', 'Zend_View_Helper');

// Set Base URL - ok *almost* naked, but you don't need this!
Zend_Controller_Front::getInstance()->setBaseUrl($_SERVER['HTTP_HOST']);

try {
    /**
     * Perform some application routing...
     *  - Could be using this as a front controller and directing all requests
     *    through this one file (provided file does not exist in file system
     *  - Note the method below is only really for demonstration, it would be
     *    horrible with a large site
     */
    switch ($_GET['page']) {
    	case 'index':
    	case 'exception':
    		$pageName = $_GET['page'];
    		break;
    	default:
    		$pageName = false;
    		break;
    }
    // Example of a page not being found...
    if (false === $pageName) {
        $responseHeader = 'HTTP/1.1 404 Page Not Found';
        throw new Exception('Page not Found');
    }

    /**
     * Add data to your view object here
     *   You may have your own controller implementation or some includes files
     *   where business logic is partly separated from view logic
     */
    $view->displayText = 'Hello from Lloyd';
    $view->buttonText  = 'I\'m not active!';

	$layout->content = $view->render("{$pageName}.phtml");
    echo $layout->render();
} catch (Exception $e) {
	// Clean out already buffered content - we don't want to display that!
	ob_clean();
    if (!isset($responseHeader)) {
    	$responseHeader = 'HTTP/1.1 500 Internal Server Error';
    }
    header($responseHeader);
    $view->exception = $e;
    $layout->content = $view->render('error.phtml');
    echo $layout->render();
}

Firstly we start output buffering, by doing this we can set our headers at any point in the request and know that it is possible to send them. Should an exception be thrown at any stage of the code execution we clean this buffer and write out or error message content and layout. This ensures that we do not deliver part rendered content containing errors to the end user.

Next a new MVC instance of Zend_Layout is generated and we tell it that out layout scripts have the extension phtml, are to be found in a directory outside of the public path, and that our default layout is called index(.phtml). From the layout we then extract the view object (to which we set our data to be presented) and apply similar setup.

Next we setup the view object with a reference to the default Zend_View helpers. View helpers are sets of additional convenience functionality. For example, writing out a float in monetary format, or creating a zebra striped table (they can be read about here). By extending Zend_View_Helper_Abstract and adding your own library at this point its possible to use your own application view helpers.

The rest of the application code is now wrapped in a try {} catch {} block. Should anything throw an uncaught exception we can catch it and display a nice error message to the end user.

Our first task within the try {} catch {} is to route our request, what does the user want to see? Here I’ve implemented some very simple demonstration code where I check the value of the ‘page’ get variable. Your routing can be very much more complex. The routing is used to call what ever code needs to be executed to get/handle data provided by the user and to tell the system what view (and possibly layout script) to use.

Ultimately if our router does not match any page it sets a 404 response code and displays a nice page not found message to the end user. Here, we throw and catch our own exception (and a very generic exception at that) but probably you’d be throwing your own exception from within the router code.

Once we’ve successfully routed our request we can begin to do something with the code. It might be that you have your own controllers/models implemented or you include some code that’s already been separated somewhat. Here I set a couple of simple variables to the view object.

Once this is completed we simply render the views with our data. If the code throws an uncaught exception for any reason this is trapped near the bottom of the script. Here we clear already buffered output, set a 500 response header, and tell our application to render the ‘error’ view script (which is generally a much stripped down version of the normal layout/view and logs the error for checking later).

As the view is rendered first and injected into the layout it is possible to change the layout from within the view, and indeed set required extras, for example,

• Page title
• Meta tags
• Scripts (URLs or code) into the &lt;head&gt; section
• Add additional styles, etc

Additionally its even possible to change the entire layout from within the view by using…

<?php $this->layout()->setLayout('alternativeLayout') ?>

…as and when required.

Finally…

I hope this has been a useful introduction to Zend_Layout and Zend_View and it will enable you to start implementing your own basic MVC and improve the maintainibility/extensibility of your code. Please take a look at the source code for examples of usage (see the README file for instructions).

The code assumes that you’ve already got autoloading working (or you have included the required classes).  In addition, I would not recommend that you implement the routing or data setting as above, this is very much simplified for demonstration. To see the full code take a look at the source code linked at the top of this article.

Zend Framework version: 1.10.6

    /**
     * Sets up layout scripts on a per-module basis
     */
    protected function _initLayoutHelper()
	{
	    $this->bootstrap('frontController');
	    $layout = Zend_Controller_Action_HelperBroker::addHelper(
	        new Pro_Controller_Action_Helper_SetLayoutPath(APPLICATION_PATH));
	}

Almost exactly the same as before except this time we pass the constant APPLICATION_PATH into the constructor as our base path.

Next the controller action helper itself now looks as follows:

/**
 * Sets the layout path on a per-module basis
 *
 * @author     Lloyd Watkin
 * @since      16/02/2010
 * @package    Pro
 * @subpackage Controller_Action_Helper
 */

/**
 * Sets the layout path on a per-module basis
 *
 * @author     Lloyd Watkin
 * @since      16/02/2010
 * @package    Pro
 * @subpackage Controller_Action_Helper
 */
class Pro_Controller_Action_Helper_SetLayoutPath
    extends Zend_Controller_Action_Helper_Abstract
{
	/**
	 * Base path
	 *
	 * @var string
	 */
	protected $_path;

	/**
	 * Construct
	 *
	 * @param string $path
	 */
	public function __construct($path)
	{
	    $this->setBasePath($path);
	}

	/**
	 * Set base path
	 *
	 * @param string $path
     */
	public function setBasePath($path)
	{
		if (!is_string($path) || empty($path)) {
			throw new Exception('Excepted string for base path');
		}
		$this->_path = $path;
	}

	/**
	 * Get the base path
	 *
	 * @return string
	 */
	protected function _getBasePath()
	{
		if (is_null($this->_path)) {
			if (!defined('APPLICATION_PATH')) {
				throw new Exception('Base path can not be determined');
			}
			$this->_path = APPLICATION_PATH;
		}
		return $this->_path;
	}

    /**
     * Sets layout path based on module
     */
    public function preDispatch()
    {
    	$module = preg_replace(
    	    '/[^A-Z]/i', '', $this->getRequest()->getModuleName()
    	);

	    if ($bootstrap = $this->getActionController()
	                       ->getInvokeArg('bootstrap')) {

	        $view = $bootstrap->getResource('view');
	        $layoutPath = $this->_getBasePath() .
	            "/modules/{$module}/layouts/scripts/";

	        /* If layout directory exists then apply it, otherwise just fall
	         * back on the default
	         */
	        if (is_dir($layoutPath)) {
	            $this->getActionController()
	                 ->getHelper('layout')
	                 ->setLayoutPath($layoutPath);
	            $view->headLink()->appendStylesheet(
	                "/styles/{$module}/style.css"
	            );
	        }
    	}
    }
}

Note the passing of our base path (cf. APPLICATION_PATH) in the constructor, we also have a getter and setter for the base path. Unlike the previous version of the code if the layouts path does not exist then the code will fall back the default layout path. If the base path is not set it will try to determine the base path from the constant APPLICATION_PATH, otherwise an exception is thrown. I’ve also cheekily thrown in a module-based style sheet for good measure

The module based layout is determined from whether the layout script path exists (obviously this method can be changed easily). This does add a little overhead from the application.ini setup (however if the layout path exists PHP will cache the result for performance*) but in return you gain the added convenience of more easily dropping in new modules.

That’s it, not much different, but you don’t need to add a new configuration entry each time you wish to add a new module :)

*To clear this cache (if required) use the clearstatcache function.

Basically but invoking an instance of the front controller its possible to grab the router and assemble a url. Assemble is the function used in the view helper. The URL is built up from an array of module, controller, action, etc, followed by a second parameter of the route to use. The code is as follows:

<?php
/**
 * View helper which returns link category URL
 *
 * @author     Lloyd Watkin
 * @since      25/01/2010
 * @package    ViewHelper
 * @subpackage LinksUrl
 */
class Pro_View_Helper_LinksUrl
    extends Zend_View_Helper_Abstract
{
	/**
	 * Returns link category URL
	 *
	 * @param  Doctrine_Record $category
	 * @param  string          $module
	 * @param  string          $controller
	 * @param  string          $action
	 * @return string Url
	 */
    public function linksUrl($category, $module = 'www',
        $controller = 'links', $action = 'index')
    {
    	$router = Zend_Controller_Front::getInstance()->getRouter();

        return $router->assemble(array(
            'module'     => $module,
            'controller' => $controller,
            'action'     => $action,
            'category'   => "{$category->id}-{$category->name}",
        ), 'www-index');
    }
}

Another way to do this is to invoke Zend_View_Helper_Url itself and call the Url method (if you want to use the helper itself). This can be done by using the following code:

<?php
/**
 * View helper which returns link category URL
 *
 * @author     Lloyd Watkin
 * @since      25/01/2010
 * @package    ViewHelper
 * @subpackage LinksUrl
 */
class Pro_View_Helper_LinksUrl
    extends Zend_View_Helper_Abstract
{
	/**
	 * Returns link category URL
	 *
	 * @param  Doctrine_Record $category
	 * @param  string          $module
	 * @param  string          $controller
	 * @param  string          $action
	 * @return string Url
	 */
    public function linksUrl($category, $module = 'www',
        $controller = 'links', $action = 'index')
    {
    	$link = new Zend_View_Helper_Url();

        return $link->url(array(
            'module'     => $module,
            'controller' => $controller,
            'action'     => $action,
            'category'   => "{$category->id}-{$slug}",
        ), 'www-index');
    }
}

Both almost identical. Not a hard thing to do in the framework but can catch you out ;)

resources.router.routes.sitemap.route                = "sitemap.xml"
resources.router.routes.sitemap.defaults.controller  = index
resources.router.routes.sitemap.defaults.action      = sitemap

Example code for outputting can be seen by creating an action in the appropriate controller (e.g. my sitemap lies in the index controller, sitemap action):

<php
class IndexController
    extends Zend_Controller_Action
{
    /**
     * Renders a sitemap based on Zend_Navigation setup
     */
    public function sitemapAction()
    {
    	echo $this->view->navigation()->sitemap();
    	$this->view->layout()->disableLayout();
    	$this->_helper->viewRenderer->setNoRender(true);
    }
}

Sitemaps can quickly and easily be generated using Zend_Navigation, a great quick tutorial (and generally very useful for Zend Framework tutorials) is Zend Casts – Dynamically creating a menu a sitemap and breadcrumbs.

When using the zend framework with modules, its obvious that if you’re running various (sub-)sites off the same application you don’t necessarily want the same layout scripts for each part. I decided to go with the following site structure:

/Application
    /controllers
        ...
    /models
    /modules
        /default
            /controllers
            /layout
                /scripts
            /views
                /scripts
        /anotherModule
            ...
    /scripts

The problem was setting up the layout scripts on a per-module basis. The answer came through using an Action Helper. Setting up the layouts on a per-module basis involves three steps:

1. Application.ini (or similar configuration setup):
   

   admin.resources.layout.layoutPath = APPLICATION_PATH "/modules/admin/layouts/scripts"
   default.resources.layout.layoutPath = APPLICATION_PATH "/modules/default/layouts/scripts"
   member.resources.layout.layoutPath = APPLICATION_PATH "/modules/member/layouts/scripts"
   affiliate.resources.layout.layoutPath = APPLICATION_PATH "/modules/affiliate/layouts/scripts"

2. Create your Action Helper:
   

   <?php
   /**
    * Sets the layout path on a per-module basis
    *
    * @author Lloyd Watkin <lloyd@evilprofessor.co.uk>
    * @since  2010-01-01
    */
   class Pro_Controller_Action_Helper_SetLayoutPath
       extends Zend_Controller_Action_Helper_Abstract
   {
       /**
        * Sets layout path based on module
        */
       public function preDispatch()
       {
       	$module = $this->getRequest()->getModuleName();
   
   	    if ($bootstrap = $this->getActionController()
   	                       ->getInvokeArg('bootstrap')) {
   
   	        $config = $bootstrap->getOptions();
   
   	        if (isset($config[$module]['resources']['layout']['layoutPath'])) {
   	            $layoutPath =
   	                 $config[$module]['resources']['layout']['layoutPath'];
   	            $this->getActionController()
   	                 ->getHelper('layout')
   	                 ->setLayoutPath($layoutPath);
   	        }
       	}
       }
   }

3. And lastly boostrap the action helper:
   

   ...
       /**
        * Sets up layout scripts on a per-module basis
        */
       protected function _initLayoutHelper()
   	{
   	    $this->bootstrap('frontController');
   	    $layout = Zend_Controller_Action_HelperBroker::addHelper(
   	        new Pro_Controller_Action_Helper_SetLayoutPath());
   	}
   ...

For developers who haven’t had time to look at the Zend Framework this course (Zend Framework: Fundamentals) offers a good overall picture of the framework introducing you to the key areas and giving enough information in order to continue. For those who have spent time looking at the framework and have followed one or two tutorials this course does not offer much beyond.

Background

I’ve been a PHP developer for around 5-6 years, and have started working with the Zend Framework on a component basis over the last 6 months. I’ve developed and/or been a developer on a couple of small Zend Framework MVC sites.  I’ll be honest, I haven’t had a huge amount of exposure to other frameworks from a coding point of view but have spent several hours researching the project websites and evaluating them.  The framework and the community surrounding Zend Framework it is quite exciting and there seem to be huge possibilities in where its going.

About the Course

The course is delivered over 9 two hour webex sessions (with a 10-minute break in the middle). The time is spent going through a set of slides provided by Zend with discussion at any time. You can use a microphone to talk to the instructor, but to be honest I didn’t see anyone use anything more than the chat window. In addition a VMWare Ubuntu machine is provided that has example code and projects set up an a trial version of Zend Studio. The course leader talks to attendees either over an integrated VoIP solution, or you can dial in using one of the many worldwide dial in numbers.

During the course the material consists of a brief overview of the Framework and the MVC pattern before heading into a sample guestbook application. The discussion demonstrated bootstrapping, Zend_Application, Db Tables, Database access, Forms, Filtering, ACL, Validating, etc, etc. Basically covering all the topics you’d require to get a basic site up an running all the time giving you the tools to go and get more advanced in the framework (although this did amount to ‘See the website’ much of the time).

Time is given to code up some examples, and to develop the ‘guestbook’ and simple ‘wiki’ application. Personally I felt that providing the code or each app and then asking us to develop what was essentially a copy alongside didn’t really provide a good learning experience. I would have preferred to develop an application similar, but not identical. to the example application with the benefit of having a guide to refer to. Alternatively building the applications from scratch with the demonstrator would of possibly led to more questions about why and how, thus giving a better understanding of the framework, after all you can look up specifics after the course.

The last lecture consisted of working on the wiki application with help/guidance from the instructor. After the course feedback was taken, it was emphasised several times through the course that Zend takes feedback very seriously, in fact apparently our version of the course was quite new. Some of the other developers in the company will be taking the course soon so it will be interesting to see if this has happened.

The course style was informal, allowed for feedback and collaboration between attendees and the instructor. The course leader was friendly, approachable (email addresses were shared for questions), and whilst his presentation from the slides was a bit shaky seemed fully competent in the framework. He was clearly someone who used the framework on a regular basis rather than someone who is taught to teach the course, I liked the ‘real world’ experience in that respect.

Overall Feeling

In some ways I found the course a waste of time, in others it was very handy. Hopefully I’ll get my reasons across clearly, and maybe provide some food for thought or useful feedback (knowing me this is unlikely!).

For myself this course was aimed at too low a level. Having gone through the quickstart guide, read Rob Allen’s Zend Framework in Action, and worked with the framework a little I didn’t really get anything too much. I would of liked the course to pick up from the end of the quickstart and develop additional skills.

That said, the course title does clearly state “Zend Framework: Fundamentals” and in that aspect the course achieves what it sets out to do. Other members of the development team that haven’t spent the time looking into the framework finished each session with enthusiasm and asked questions which was really nice to see.

All was not lost, it was good to spend time confirming the basic details of the framework and get to ask a couple of questions in areas where I wasn’t 100%. It was also time that I got to sit down each day and think about coding using the framework and future projects, something I wouldn’t of been able to do otherwise (can you imagine your company agreeing to that? :) ). Last but not least you also get a nice certificate from Zend to say that you attended the course (albeit by email).

Zend Framework Certification

This was one question that kept coming to mind during the course, would it prepare me for the certification? The quick, easy is a resounding No. The course instructor was quite clear on that with the additional advice that for the certification you should really be using the framework on a day to day basis and feel very comfortable and confident in its usage and methodologies.

Summary

Given everything I’ve written above, I’ll summarise everything in two easy bullet points:

• New to Zend Framework: This course does exactly what you’d expect, it gives you a nice introduction to the framework and a good grounding on the basics from which you can build. The course seems to generate interest and enthusiasm for the framework amongst developers.
• Used the Zend Framework: While it was nice to shore up some of the very basics I felt the time, effort, and funds to take the course could of been better spent elsewhere. It will be nice to see  Zend create a new higher level course to take developers to the next level – at least to the standard of certification and beyond. For that I would sign up immediately.

// Set up logging to DB
$db = Zend_Registry::get('dbAdapters');
$db = $db['general'];

$logger->info('Informational message');

Where the array keys in $columnMapping are my column names. ‘Priority’ and ‘message’ are understood by Zend_Log_Writers but the additional fields were added to give me some additional information.

Obviously this assumes that you have logging working using one of the other writers first :)