The easiest way to do this is to use the ServiceManger's initialiser feature. This allows you to write one piece of injection code that can be applied to multiple objects. It's easier to show this in action!

Let's assume that we have this configuration file:

config/autoload/global.php:

return array(
    'application' => array(
        'setting_1' => 234,
    )
);

That is, we have a key called 'application' that contains application-specific configuration that we would like to access in our controllers (or service classes).

Firstly we define a interface, ConfigAwareInterface:

module/Application/src/Application/ConfigAwareInterface.php:

namespace Application;
 
interface ConfigAwareInterface
{
    public function setConfig($config);
}

We can now add this to a controller:

module/Application/src/Application/Controller/IndexController.php:

namespace Application\Controller;
 
use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;
use Application\ConfigAwareInterface;
 
class IndexController extends AbstractActionController
    implements ConfigAwareInterface
{
    protected $config;
 
    public function setConfig($config)
    {
        $this->config = $config;
    }
 
    // action methods, etc.
}

In the controller, we add a use statement, implement our interface and the required setConfig() method.

Finally, we add an initializer to the Module class:

module/Application/Module.php:

class Module
{
    // Other methods, such as OnBoostrap(), getAutoloaderConfig(), etc.
 
    public function getControllerConfig()
    {
        return array(
             'initializers' => array(
                function ($instance, $sm) {
                    if ($instance instanceof ConfigAwareInterface) {
                        $locator = $sm->getServiceLocator();
                        $config  = $locator->get('Config');
                        $instance->setConfig($config['application']);
                    }
                }
            )
        );
    }
}

(We also have a use Application\ConfigAwareInterface; statement at the top!)

As getControllerConfig() is used by a specific ServiceManager only for controllers, we need to retrieve the main ServiceManager using getServiceLocator() in order to collect the merged configuration. As we only want the settings from within the 'application' key, we only pass that into the controller's setConfig() method.

The configuration settings are now available to us in any controller that implements ConfigAwareInterface.

We can also do this for service classes - we simply add another initalizer to the Module:

module/Application/Module.php:

    public function getServiceConfig()
    {
        return array(
             'initializers' => array(
                function ($instance, $sm) {
                    if ($instance instanceof ConfigAwareInterface) {
                        $config  = $sm->get('Config');
                        $instance->setConfig($config['application']);
                    }
                }
            )
        );
    }

It also follows that you can use initializers for any type of generic injection, such as mappers, db adapters, loggers, etc. Simply create an interface and write an initalizer.

To the bottom of my .tmTheme file, I added this just above the closing </array>:

        <dict>
            <key>name</key>
            <string>diff.header</string>
            <key>scope</key>
            <string>meta.diff, meta.diff.header</string>
            <key>settings</key>
            </dict><dict>
                <key>foreground</key>
                <string>#009933</string>
            </dict>
 
        <dict>
            <key>name</key>
            <string>diff.deleted</string>
            <key>scope</key>
            <string>markup.deleted</string>
            <key>settings</key>
            </dict><dict>
                <key>foreground</key>
                <string>#DD5555</string>
            </dict>
 
        <dict>
            <key>name</key>
            <string>diff.inserted</string>
            <key>scope</key>
            <string>markup.inserted</string>
            <key>settings</key>
            </dict><dict>
                <key>foreground</key>
                <string>#3333FF</string>
            </dict>
 
        <dict>
            <key>name</key>
            <string>diff.changed</string>
            <key>scope</key>
            <string>markup.changed</string>
            <key>settings</key>
            </dict><dict>
                <key>foreground</key>
                <string>#E6DB74</string>
            </dict>

This sets up a green colour for the meta information, blue for added lines, red for deleted lines and a yellowish colour for changed.

To do this, I started with the Application's Module class and added an event listener:

    public function onBootstrap($e)
    {
        $eventManager = $e->getApplication()->getEventManager();
        $eventManager->attach('dispatch.error', function($event){
            $exception = $event->getResult()->exception;
            if ($exception) {
                $sm = $event->getApplication()->getServiceManager();
                $service = $sm->get('Application\Service\ErrorHandling');
                $service->logException($exception);
            }
        });
    }

This code attaches an anonymous function to the 'dispatch.error' event which retrieves the exception from the event's result and passes it to the logException() method in an ErrorHandling class. We retrieve ErrorHandling from the service manager which allows us to inject an instance of Zend\Log into it:

    public function getServiceConfig()
    {
        return array(
            'factories' => array(
                'Application\Service\ErrorHandling' =>  function($sm) {
                    $logger = $sm->get('Zend\Log');
                    $service = new ErrorHandlingService($logger);
                    return $service;
                },
                'Zend\Log' => function ($sm) {
                    $filename = 'log_' . date('F') . '.txt';
                    $log = new Logger();
                    $writer = new LogWriterStream('./data/logs/' . $filename);
                    $log->addWriter($writer);
 
                    return $log;
                },
            ),
        );
    }

There's obviously a few use statements at the top of the file for this to work:

use Application\Service\ErrorHandling as ErrorHandlingService;
use Zend\Log\Logger;
use Zend\Log\Writer\Stream as LogWriterStream;

The logging itself is done within the ErrorHandling class:

namespace Application\Service;
 
class ErrorHandling
{
    protected $logger;
 
    function __construct($logger)
    {
        $this->logger = $logger;
    }
 
    function logException(\Exception $e)
    {
        $trace = $e->getTraceAsString();
        $i = 1;
        do {
            $messages[] = $i++ . ": " . $e->getMessage();
        } while ($e = $e->getPrevious());
 
        $log = "Exception:\n" . implode("\n", $messages);
        $log .= "\nTrace:\n" . $trace;
 
        $this->logger->err($log);
    }
}

The logException method simply creates a string containing the exception's message along with any previous exception messages and the trace. We then call the Log's err method to store the log and can peruse at our leisure.

Update: I have updated the logException method to use a do..while() loop as it's neater and doesn't cause a an out-of-memory error that the previous code did. That is, it's a good idea to reuse the same variable when calling getPrevious()!

In this case, I discovered that setting stdFont: Helvetica-Light or stdFont: HelveticaLight in the style file resulted in Verdana being used in the PDF file!

Fortunately, the -v switch to rst2pdf is your friend when you want to know what's happening:

[INFO] findfonts.py:270 Trying to embed Helvetica-Light
[INFO] findfonts.py:307 fname for findTTFont: Helvetica-Light
[INFO] findfonts.py:308 Variants via findTTFont: ['/Library/Fonts/Microsoft/Verdana.ttf', '/Library/Fonts/Microsoft/Verdana Bold.ttf', '/Library/Fonts/Microsoft/Verdana Italic.ttf', '/Library/Fonts/Microsoft/Verdana Bold Italic.ttf']
[INFO] findfonts.py:317 Registering font: Verdana from /Library/Fonts/Microsoft/Verdana.ttf
[INFO] findfonts.py:317 Registering font: Verdana Bold from /Library/Fonts/Microsoft/Verdana Bold.ttf
[INFO] findfonts.py:317 Registering font: Verdana Italic from /Library/Fonts/Microsoft/Verdana Italic.ttf
[INFO] findfonts.py:317 Registering font: Verdana Bold Italic from /Library/Fonts/Microsoft/Verdana Bold Italic.ttf
[INFO] findfonts.py:329 Embedding via findTTFont as ['Verdana', 'Verdana Bold', 'Verdana Italic', 'Verdana Bold Italic']

As can be seen by the output, rst2pdf can't find Helvetica-Light and so has substituted Verdana instead. This would seem to be because it couldn't find a TTF file for the font on my Mac as Helvetica Light is stored in a dfont file.

To solve this, I used DFontSplitter to extract Helvetica Light as a separate TTF file and added this as an embedded font to the style file:

embeddedFonts: []
    [fonts/HelveticaLight.ttf, fonts/HelveticaLight.ttf, fonts/HelveticaLight.ttf, fonts/HelveticaLight.ttf]

and re-ran with -v which gave me this information:

[INFO] styles.py:276 Registering font: fonts/HelveticaLight from ./fonts/HelveticaLight.ttf

I now know that the name to use when referencing this font is "fonts/HelveticaLight" and so I can use it within the style file like this:

stdFont: fonts/HelveticaLight

and the font is embedded as I expected.

I've recently been using Capistrano for deployment and other remote tasks and it's proving quite useful.

One problem I ran into was that the umask was being set to 022 when using Capistrano and 002 when I was ssh'd into the server itself.

After a bit of research, I discovered that the secret is to put the umask statement in my .bashrc file before the line that says [ -z "$PS1" ] && return as when Capistrano logs into the server, it doesn't have an interactive shell (and so $PS1 isn't set.

My .bashrc now looks like this:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
 
umask 002
export PATH=~/bin:$PATH
 
# If not running interactively, don't do anything
[ -z "$PS1" ] && return

(This is on Ubuntu 12.04 LTS)

I'm really excited by this new phase of my career. I have created a shiny new company for interesting projects: Nineteen Feet Limited. If you want to hire me, then please get in touch.

Over the years, I've discovered that I most enjoy developing directly for a client and building solutions that meet their specific needs. I've had great success teaching at conferences (such as PHPNW and ZendCon) and am looking forward to providing bespoke Zend Framework training to developers.

An entity

My entities are plain old PHP objects:

namespace Book;
 
class Entity
{
    protected $id;
    protected $author;
    protected $title;
    protected $isbn;
 
    public function __construct($data = array())
    {
        $this->populate($data);
    }
 
    // Data transfer methods
 
    public function populate($data)
    {
        if (array_key_exists('id', $data)) {
            $this->setId($data['id']);
        }
        // repeat for other properties
    }
 
    public function getArrayCopy()
    {
        return array(
            'id'     => $this->getId(),
            // repeat for other properties
        );
    }
 
    // Entity-specific methods
 
    public function isValidIsbn()
    {
        // validate ISBN and return true/false
    }
 
    // Property getters and setters
 
    public function getId()
    {
        return $this->id;
    }
 
    public function setId($id)
    {
        $this->id = $id;
        return $this;
    }
 
    // Repeat for other properties...
 
}

There's nothing particularly complicated here. We have an object with a number of properties and some methods. This object represents a book, so we have properties of author, title and isbn. We need to be able to set and retrieve the properties so there is a get and set method for each one (only getId() and setId() are in the code snippet above to save space!)

Generally, I populate an entity from a mapper and use a pair of methods to do this: populate() and getArrayCopy(). These methods transfer the data in the properties to and from an array.

There are also entity-specific methods within the entity. For this object, I have a method called isValidIsbn(); for a user object, I may have a method called getFullName() which concatenates the user's first name and surname.

A mapper

The mapper knows how to load and save entities. This is a hand-rolled one:

namespace Book;
 
use PDO;
use Book\Entity;
 
class Mapper
{
    protected $pdo;
 
    public function __construct($dsn, $username, $password)
    {
        $this->pdo = new PDO($dsn, $username,  $password);
    }
 
    public function loadById($id)
    {
        $sql = 'SELECT * FROM book WHERE id = :id';
 
        $statement = $this->pdo->prepare($sql);
        $statement->setFetchMode(PDO::FETCH_ASSOC);  
        $statement->execute(array('id' => $id));
 
        $result = $statement->fetch();
        if ($result) {
            $book = new Entity($result);
            return $book;
        }
 
        return false;
    }
 
    public function fetchAll($order)
    {
        // Select all books from database using PDO
        // iterate over each one and create a Book\Entity object
    }
 
    public function save(Entity $book)
    {
        $data = $book->getArrayCopy();
        if ($data['id'] > 0) {
            // Update data in table using PDO and set $result
        } else {
            // Insert data into table using PDO and set $result
        }
 
        return $result;
    }
 
    public function delete($id)
    {
        // Delete row in table using PDO
    }
}

In the mapper, I have methods that load with multiple entities and also ones that work on a single one. I like to use the method prefix "find" for methods that will return an array of entities and "load" for methods that return a single entity. This is just a stylistic thing, but I find it makes reading code easier. We then have save and delete methods that allow us to save and remove an entity from the data store.

This is just a skeleton of a specifically written mapper that users PDO. In a ZF2 application I use ZfcBase\Mapper\AbstractDbMapper and in other applications I tend to abstract the common code into a base class and extend.

Service objects

Lastly, service objects provide the API to the rest of the application:

namespace Book;
 
use Book\Mapper;
 
class Service
{
    protected $mapper;
 
    public function __construct(Mapper $mapper)
    {
        $this->mapper = $mapper;
    }
 
    public function fetchAllByTitle()
    {
        $results = $this->events->trigger(__FUNCTION__.'.pre', $this, array(), 
            function ($result) {
                return is_array($result);
            }
        );
        if ($results->stopped()) { 
            return $results->last(); 
        }
 
        $books = $this->mapper->fetchAll('title');
 
        $this->getEventManager()->trigger(__FUNCTION__.'.post', $this, 
            array('books' => $books));
 
        return $books;
    }
 
    public function loadById($id)
    {
        $results = $this->events->trigger(__FUNCTION__.'.pre', $this, 
            array('id' => $id), 
            function ($result) {
                return ($result instanceof Book\Entity);
            }
        );
        if ($results->stopped()) { 
            return $results->last(); 
        }
 
        $book = $this->mapper->loadById($id);
 
        $this->getEventManager()->trigger(__FUNCTION__.'.post', $this, array('book' => $book));
 
        return $book;
    }
 
    // etc
}

A simple service object essentially proxies through to the mapper. I generally have more specific methods, such as fetchAllByTitle(), but that's a personal preference. In this example, I have an ZF2 event manager in play and the service object triggers events as required.

The service object is also useful when there are multiple related objects. For instance, if books had tags that were loaded separately, then I would have a method such as loadTagsIntoBook($book) on this service object. Of course, others prefer to use an ORM, such as Doctrine for these things.

Summary

This overview shows the type of methods that I have in each type of core object in my model layer. My controllers and view helpers only ever deal with service objects and entities, so I can change my mapper at any time.

You also need to think carefully where the business logic lives. I'm a fan of putting the logic in the entities as well as in service objects. Others tend to like their entities to be quite "dumb", though.

As Chris Shiflett wrote earlier this month, real writing happens on blogs. With a blog you have the space to write down what you mean and develop the idea. However, even here there is risk. Lorna Mitchell noted that comments make it easy to criticise. You can leave an quick "drive-by" insult anonymously for minimal effort. This can become a disincentive to write opinion pieces on blogs too.

Like Chris, I also strongly believe in owning my data. My blog provides information that I want to share and more important, information that I want to find again! I was caught out on my Automatic Apache vhosts post where I linked to an alternative solution which has subsequently been taken down. Information that I want to refer to again must be on my blog as otherwise I can't be sure it'll be there when I need it.

I will continue to share technical things on this site as I believe that my posts are useful to others. Over time, I intend to blog more opinionated pieces. My views on some topics should be shared and would be a useful reference to point people at. Sometimes, I will turn off comments and encourage others to respond by writing their on their own blog. In more than 140 characters and less anonymously.

Entities are objects that represent something in my business logic. For example, in my traditional Album's tutorial, the entity would be the object that holds one album. It has properties such as title, artist and date created and methods that are specific to this entity.

Mappers know how to save and load an entity from the data store. This could be a database or a web service or an CSV file on disk. There is no requirement that a given entity maps to a single database table (or file on disk) as the mapper can simply use multiple tables for different properties within the entity if it wants to. The entity has no knowledge of how it is loaded and saved. This isolation means that I can have multiple mappers for the same entity that store it to different data stores.

Service objects provide the API that the rest of the application uses. I allow controllers and view helpers to talk to service objects, though I appreciate that others have a different take on MVC. Any given service object knows about mappers and entities and anything else that the business logic requires. I like having a service object as I can rework which mappers do what without having to touch the rest of the application. The service layer also know about other app details such as sending emails after a form is submitted. In an event based system, such as a ZF2, these details can now live in their own objects which listen for events triggered by the service object.

I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

        $this->add(array(
            'name' => 'next_appointment',
            'type' => 'Zend\Form\Element\DateTime',
            'options' => array(
                'label' => 'Next callback time',
            ),
            'attributes' => array(
                'min' => '1 Jan 2013, 00:00',
            ),
        ));
        $this->get('next_appointment')->setFormat('j M Y, H:i');

The two things to note:

1. You can't set the format within the array - it has to be via a setFormat() call.
2. If you change the format, you must set the min attribute in the same format, as otherwise it will try to set it with the hardcoded string of '1970-01-01T00:00Z' which will not work with your specified format.