My adventure into Kiwi-land started with a long and interesting trip to San Francisco. The interesting part was my new book: Domain Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans. This book, combined with KLM’s excellent on-board service made my flight to SF a breeze.

It was only 2PM when I arrived in SF, so I had to wait another 4 hours before my flight to Auckland even boarded. The waiting wasn’t too bad. It was great to get out into the sun and to grab some decent food and coffee. Didn’t get to see much of SF though, which was too bad.

The flight to Auckland wasn’t that flawless unfortunately. There were some technical problems with the airplane, which caused quite a bit of a delay. Because of this delay I had to run to catch my flight to Dunedin. The flight was all set to go and was waiting for me… I barely made it in time!

When I got to Dunedin I was welcomed by Jesse, Tracey and Lindsay. It was great to meet them in person. The first order of business for me was to get some coffee, because I only got roughly 3 hours of sleep on my way there. After a little tour of Abbey College (that’s where I’m staying) it was time for our first meeting. No time for sleep! Finally, after dinner at Abbey, I decided it was time to get some sleep. When I woke up the next day, the jet-lag was no more!

Abbey is a great place to stay by the way. It’s not far from the office or from the city center. The people who are staying there are great as well. Just check out the site. Abbey’s got it all!

So what am I doing here in NZ? We’re currently working on writing the software for the PBRF initiative. It has already taken a lot of late hours, and it will probably take a lot more. It will be worth it though! After that, we’ll be working on a great and exciting cutting-edge open-source project. Unfortunately I can’t say a lot more at this point, but you can rest assured that it includes the latest Zend Framework technologies.

Seeing as I don’t have internet-access at Abbey College yet, I’ve got lots of time for other activities. I’ve finished reading the better part of my Domain Driven Design book and I’ve ordered Martin Fowler’s Patterns Of Enterprise Application Architecture, which should arrive this week. I’ve also bought myself a brand new bicycle so I can get around. Cycling here is a bit more dangerous than in the Netherlands though… it definitely brings back memories from my bicycling trip in Scotland! There are lots more things on my todo list: winery tour, surfing, snowboarding, skydiving, bungee-jumping, renting/buying a Harley… six months in NZ is not going to be enough time!

Well, that’s my first NZ blog-post. There will definitely be more of these! Let’s hope they fix my internet soon… See my Flickr photo-stream for more pictures.

So what’s the big deal about those properties? In short, they make a developers life easier by allowing the developer to code no more than needed at that moment. And lets face it… less code is better! In this post we’ll see that it’s not impossible to enjoy properties in PHP today. As with a lot of good things, it does come with a small price though…

Lets have a look at a use-case to demonstrate where properties will not only save you time, but it will also save your sanity. In this example we’re modeling a Person class. In the beginning of the project, the requirements for the Person class are quite simple: a Person has an age and a name. In the simplest form we can code that as follows:

<?php
class Person
{
    public $age;

    public $name;
}

This look easy enough, and it is. It even works like a charm and it’s possibly the fastest implementation for the Person class.

But, pesky as they are, the client suddenly wants some logic added to our Person class! A Person suddenly can’t be younger than 21 years old. This poses a problem. To add logic to our Person class, we would have to switch the public age attribute with a pair of getters and setters:

<?php
class Person
{
    private $_age = null;

    public $name = null;

    public function getAge()
    {
        return $this->_age;
    }

    public function setAge($age)
    {
        if ($age < 21) {
            throw new Exception('You need to be at least 21 years or older!');
        }

        $this->_age = $age;
    }
}

Technically this works like a charm, however it will force me to go through my entire application and switch all references from the public attribute to the getter and setter. Not an ideal situation. One possible solution is to do things the Java way: just create all getters and setters up-front so you don’t have to do so afterwards. Even though this works fine, it’s in violation of our mission to write no more code than we actually need at the moment of writing.

The solution? Properties! But wait… PHP doesn’t support those, remember? Luckily we still have magic methods. It’s nowhere near as nice as a native solution, but at least it helps us write no more code than we need at the moment we’re first writing our code:

<?php
abstract class ModelAbstract
{
    public function __get($key)
    {
        $method = 'get' . ucfirst($key);

        if (!method_exists($this, $method)) {
            throw new Exception('No property found for ' . $key);
        }

        return $this->$method();
    }

    public function __set($key, $value)
    {
        $method = 'set' . ucfirst($key);

        if (!method_exists($this, $method)) {
            throw new Exception('No property found for ' . $key);
        }

        $this->$method($value);
    }
}

We’ll take a look at what this does exactly later. The important thing to note is that we can now do the following:

<?php
class Person extends ModelAbstract
{
    private $_age = null;

    public $name = null;

    public function getAge()
    {
        return $this->_age;
    }

    public function setAge($age)
    {
        if ($age < 21) {
            throw new Exception('You need to be at least 21 years or older!');
        }

        $this->_age = $age;
    }
}

$person = new Person();

try {
    $person->age = 10;
} catch (Exception $e) {
    // Will print "You need to be at least 21 years or older!"
    echo $e->getMessage();
}

With this construction in place, we can safely switch from a public attribute to getters and setters, without changing the rest of the application code. The only real downside to this – aside from the minor speed impact – is the fact that you have to subclass ModelAbstract to make this work. Luckily it’s not a lot of code, so should there be a big need to get rid of the ModelAbstract inheritance it’s not a big disaster to do some copy/paste work.

This method works by assuming you have get- and set methods that have the same name as the property you’re trying to access. When there’s a public attribute, it will use that. If there’s no public attribute, it will fall back to __get or __set and the logic will take it from there.

All of this is just a proof-of-concept of implementing properties in PHP and of the way I want to be using properties to access data the data in my objects. Please comment your experiences with this approach or similar approaches. I’m curious to see how practical this solution would be in a real-life situation.

So why would you want to apply filters to your result set? Usually my domain models don’t inherit from Zend_Db_Table_Row but that is the data type I get from the Paginator when I use the DbTableSelect adapter (wrapped in a nice Zend_Db_Table_Rowset). Instead, I would like to load my rows into my models and preferably without using the Paginator abilities or having to apply weird hacks. Previously this was only possible (in a sane way) by subclassing an adapter so it could return a collection of model objects instead of a rowset. With the new filter support you can just inject a filter to do this for you.

Lets have a look at an example. In this example I want to list all my users from the database. I’ll grab the name of the user from the row and inject it into a User object.

<?php
class User
{
    private $_name = '';

    public function getName()
    {
        return $this->_name;
    }

    public function setName($name)
    {
        $this->_name = $name;
    }
}

class UserFilter implements Zend_Filter_Interface
{
    public function filter($rows)
    {
        $users = array();

        foreach ($rows as $row) {
            $user = new User();
            $user->setName($row->name);

            $users[] = $user;
        }

        return $rows;
    }
}

class MyModel
{
    public static function getUserPaginator()
    {
        $userTable = new UserTable();
        $paginator = Zend_Paginator::factory($userTable->select());
        $paginator->setFilter(new UserFilter());

        return $paginator;
    }
}

$paginator = MyModel::getUserPaginator();
$items = $paginator->getCurrentItems();

foreach ($items as $user) {
    echo 'Current name: ' . $user->getName() . '<br />' . PHP_EOL;
}

To simplify adding a simple filter to your paginator I’ve also added Zend_Filter_Callback. This allows you to specify a callback method that does the same as the filter in the previous example.

<?php
class MyModel
{
    public static function getUserPaginator()
    {
        $userTable = new UserTable();
        $paginator = Zend_Paginator::factory($userTable->select());
        $paginator->setFilter(new Zend_Filter_Callback(
            array('MyModel', 'filter'))
        );

        return $paginator;
    }

    public static function filter($rows)
    {
        $users = array();

        foreach ($rows as $row) {
            $user = new User();
            $user->setName($row->name);

            $users[] = $user;
        }

        return $rows;
    }
}

The callback also accepts object instead of a static reference to a class. Internally it uses call_user_func to execute the filter() method, so any notation that works there, works with the Callback filter.

Enjoy!

<?php
class Bar
{
    private $_foo = 'foo';

    public function get foo()
    {
        return $this->_foo;
    }

    public function set foo($fooString)
    {
        $this->_foo = $fooString;
    }
}

$bar = new Bar();
$bar->foo = 'baz';
echo $bar->foo; // prints baz