Fat Models, Chubby Routes, Super-Skinny Controllers

We have just started a blog at work where we will be writing about some of the technologies we use daily. I just wrote a post about beefing up the routes in Zend Framework applications.

Read all about it over at VG Tech.

I will continue to write on this blog, but if you are interested in web technologies be sure to checkout VG Tech as well.

Advertisements
Posted in PHP, Technology, Work related | Tagged , , | Leave a comment

Playing with traits in PHP 5.4alpha1

PHP 5.4alpha1 was released the other day with some cool new features. One of them is an implementation of traits. From the RFC:

Traits is a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way, which reduces complexity and avoids the typical problems associated with multiple inheritance and Mixins.

There are some nice examples over at the RFC, and I will provide another example in this post.

But first, to be able to play with this we need to build PHP. It’s the usual ./configure; make; make test; dance so it should not pose too many problems. The make test step is optional, but every time you skip that step, God creates another Perl programmer, so please, make test. If you run into any problems building PHP you will have to look elsewhere for answers. I won’t cover that in this post.

Now that you have built PHP, lets start writing some code.

When working on a framework (or something else for that matter), you will most likely need to introduce parameters for some of your classes, be it database adapters or a storage adapter. All these classes will most likely have the following methods:

  • setParams(array $params)
  • getParams()
  • setParam($key, $value)
  • getParam($key)

The implementation of these methods will most likely be the same. If you put the actual implementation of these methods in many classes you’re not DRY anymore. Since PHP does not support multiple inheritance you will have to make a base class with the implementation of these methods, and have other classes ultimately extend this base class. Now you are relatively DRY, but this solution is not optimal(and sometimes not possible at all).

Enter traits, the newest superhero on the PHP street, or something like that.

Now, I’ll create two classes that needs to support parameters; Cogo\Database\MySQL and Cogo\Storage\Filesystem. They will each extend Cogo\Database and Cogo\Storage respectively that will have the parameter-related methods.

<?php
namespace Cogo;

abstract class Database {
    private $params;

    public function __construct(array $params) {
        $this->setParams($params);
    }

    private function setParams(array $params) {
        $this->params = $params;
    }

    public function getParams() {
        return $this->params;
    }

    protected function setParam($key, $value) {
        $this->params[$key] = $value;
    }

    public function getParam($key) {
        return (isset($this->params[$key]) ? $this->params[$key] : null);
    }

    protected function someDatabaseRelatedMethod() {
        // ...
    }

    abstract protected function someOtherDatabaseRelatedMethod();
}
<?php
namespace Cogo\Database;
use Cogo\Database;

class MySQL extends Database {
    protected function someOtherDatabaseRelatedMethod() {
        // ...
    }
}
<?php
namespace Cogo;

abstract class Storage {
    private $params;

    public function __construct(array $params) {
        $this->setParams($params);
    }

    public function setParams(array $params) {
        $this->params = $params;
    }

    public function getParams() {
        return $this->params;
    }

    public function setParam($key, $value) {
        $this->params[$key] = $value;
    }

    public function getParam($key) {
        return (isset($this->params[$key]) ? $this->params[$key] : null);
    }

    protected function someFilesystemRelatedMethod() {
        // ...
    }

    abstract protected function someOtherFilesystemRelatedMethod();
}
<?php
namespace Cogo\Storage;
use Cogo\Storage;

class Filesystem extends Storage {
    protected function someOtherFilesystemRelatedMethod() {
        // ...
    }
}

As you can see the parameter-related methods are almost the same. The difference is that the Cogo\Database class wants to have its set methods private and protected.

One possibility would be to create a base class for the parameter handling, and have the two abstract classes extend that one, but because multiple inheritance is not possible in PHP it’s easy to grind to a halt using this solution. In the end you might end up with a huge base class with loads of logic simply because it has some logic that you want to share across many other classes.

The base class would also have to have private on the set methods since you can’t override a method with a stricter visibility, only the other way around.

Using traits, this can be solved in a more elegant fashion. Traits also support changing visibility of the methods defined in the trait, so Cogo\Database can keep its private and protected implementations. Here is how the trait can look like:

<?php
namespace Cogo;

trait ParamsHandler {
    private $params;

    public function __construct(array $params) {
        $this->setParams($params);
    }

    public function setParams(array $params) {
        $this->params = $params;
    }

    public function getParams() {
        return $this->params;
    }

    public function setParam($key, $value) {
        $this->params[$key] = $value;
    }

    public function getParam($key) {
        return (isset($this->params[$key]) ? $this->params[$key] : null);
    }
}

Notice that the trait now contains all logic regarding parameters (including the $params property and the constructor). The RFC states that:

Since Traits do not contain any state/properties …

This seems to work after all. The RFC was created a while ago and it no longer matches the actual implementation 100% obviously.

Now that we have a trait with the logic we want in both our abstract classes, let’s use it:

<?php
namespace Cogo;

abstract class Database {
    use ParamsHandler {
        setParams as private;
        setParam as protected;
    }

    protected function someDatabaseRelatedMethod() {
        // ...
    }

    abstract protected function someOtherDatabaseRelatedMethod();
}
<?php
namespace Cogo;

abstract class Storage {
    use ParamsHandler;

    protected function someFilesystemRelatedMethod() {
        // ...
    }

    abstract protected function someOtherFilesystemRelatedMethod();
}

As you can see we have replaced the implementation of the parameter methods from both abstract classes with a couple of use statements. In the Cogo\Storage class we have used the methods from the trait as-is, which means they are all public. In the Cogo\Database class we have changed the visibility of two methods to match the initial implementation. We have now managed to keep ourselves DRY, as well as not creating a base class that the two abstract classes extends.

This is just a simple example of how to use traits. They can do loads more, and there are issues like for instance conflict resolution which is not mentioned in this post at all. I will probably post more examples of traits (and perhaps other 5.4 features) later on. In the meantime you should read the RFC, and try it out for yourself.

You will find all the code mentioned in this post over at my php-traits-examples repository at GitHub. Feel free to play around with it, and if you have other examples on how to use traits please fork the project and send me a pull request so I can include it (and learn from it).

Posted in PHP, Technology | Tagged , , | 7 Comments

Mocking MongoCollection with Mockery

I have played around with the mongo extension to PHP lately and came across an issue when I was trying to write unit tests with PHPUnit for some methods using MongoCollection::insert().

Consider a class method looking like this:

class Database {
    public function insertData($hash, Image $image) {
        $data = array(
            'hash' => $hash,
            'name' => $image->getName(),
        );

        $this->getCollection()->insert($data, array('safe' => true));
        $image->setId((string) $data['_id']);

        return true;
    }

    // ...
}

The Image class is just some custom class, and the getCollection() method returns a property set in the class (so I can inject mocked versions of the collection and not depend on MongoCollection).

As you see from the code above the insertData() method changes the first parameter (it adds an _id element that is set to an instance of MongoId). The problem with testing the above method is that when mocking MongoCollection you can’t make it add the _id element to the passed array, so the test fails because of an E_NOTICE that says:

Undefined index: _id.

I tried to solve the problem by using Mockery (a simple but flexible (and awesome) mock object framework by Pádraic Brady) like this:

public function testInsertData() {
    $id = MongoId();
    $idAsString = (string) $id;
    $image = \Mockery::mock('Image');
    $image->shouldReceive('setId')
          ->once()
          ->with($idAsString)
          ->andReturn($image);
    $image->shouldReceive('getName')
          ->once()
          ->andReturn('some name');

    $collection = \Mockery::mock('MongoCollection');
    $collection->shouldReceive('insert')
               ->once()
               ->with(\Mockery::on(
                   function(&$data) use($id) {
                       $data['_id'] = $id;
                       return true;
                   }), \Mockery::type('array'));

    // The object we want to test with
    $database = new Database;
    $database->setCollection($collection);
    $database->insertData($hash, $image);
}

When running the above test I get the following error:

Parameter 1 to {closure}() expected to be a reference, value given

This is because Mockery uses the call_user_func_array function to call the closure given to \Mockery::on(), and that function does not support references. PHPUnit also uses this function internally for its mock objects.

The description of MongoCollection::insert() in the PHP manual looks like this:

public mixed MongoCollection::insert ( array $a [, array $options = array() ] )

Feeling a bit bold I tried to change the insertData() method above to pass an instance of stdClass instead of an array to MongoCollection::insert(). Why? Objects in PHP-5 are all references, so I might be able to get Mockery to work without having to specify &$data in the closure. It’s not documented, but hey, you never know without trying right? Here is the new version of insertData():

public function insertData($hash, Image $image) {
    $data = new stdClass;
    $data->hash = $hash;
    $data->name = $image->getName();

    $this->getCollection()->insert($data, array('safe' => true));
    $image->setId((string) $data->_id);

    return true;
}

The only change I made in the test method was to change the closure I give to \Mockery::on() from:

function(&$data) use ($id) {
    $data['_id'] = $id;
    return true;
}

to

function($data) use ($id) {
    $data->_id = $id;
    return true;
}

and voila, the test works! The part about giving an instance of stdClass to MongoCollection::insert() is not documented, and I’m not sure if it’s a feature that’s going to stay implemented.

At first I tried to solve this using the built in mock objects in PHPUnit, but since they clone the objects used in the mocks the trick above would not work anyway as the change would not be made on the correct reference.

And thats that!

Posted in PHP, Technology | Tagged , , , , , , | Leave a comment

Changed blog theme

I just changed the theme on this blog to the default WordPress theme. Please let me know if anything looks weird.

Posted in Misc | Leave a comment

How to set up your own PEAR channel

If you want to make your projects available to users as PEAR packages you will most likely want a PEAR channel. This way users can install/upgrade/remove your packages by using the pear command. There are a couple of solutions available when setting up your own channel. One of the most popular is called Pirum, which I will be covering in this post.

Pirum is a simple and nice looking PEAR channel server manager that lets you setup PEAR channel servers in a matter of minutes. Pirum is best suited when you want to create small PEAR channels for a few packages written by a few developers.

First you will need to install Pirum. This can be done via pear:

christer@aurora:~$ sudo pear channel-discover pear.pirum-project.org
Adding Channel "pear.pirum-project.org" succeeded
Discovery of channel "pear.pirum-project.org" succeeded
christer@aurora:~$ sudo pear install pirum/Pirum
downloading Pirum-1.0.0.tgz ...
Starting to download Pirum-1.0.0.tgz (11,732 bytes)
.....done: 11,732 bytes
install ok: channel://pear.pirum-project.org/Pirum-1.0.0

If your PEAR environment is set up correctly you should now have an executable called pirum. Run the command to see what it can do:

christer@aurora:~$ pirum
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

The first thing you want to do is just choose a target directory for where you want to have your channel along with the packages served by the channel. Create the target directory and add a file called pirum.xml inside it that will be used by pirum when building the channel. The file can look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<server>
  <name>pear.starzinger.net</name>
  <summary>Starzinger PEAR channel</summary>
  <alias>stz</alias>
  <url>http://pear.starzinger.net/</url>
</server>

This is the pirum.xml file I used when setting up pear.starzinger.net. Most tags are self descriptive except for the <alias> tag. That is the “shortcut” users can use when querying your channel. If you look at how I installed pirum above you can see that I used the “pirum” alias in the install command. The Starzinger PEAR channel uses “stz” so when querying the channel you can just do:

christer@aurora:~$ pear list -c stz
Installed packages, channel pear.starzinger.net:
================================================
Package        Version State
PHP_BitTorrent 0.0.1   alpha
SqlDiff        0.0.3   beta

Now that the pirum.xml file is in place, run the following command to build the channel:

christer@aurora:~$ pirum build /var/www/pear
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the build command:
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building releases
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command build run successfully

Now you will need to setup apache to have a host pointing to the newly created channel. This can be done for instance via a regular VirtualHost setup:

<VirtualHost *:80>
        ServerName pear.starzinger.net
        DocumentRoot /var/www/pear
</VirtualHost>

Now, when browsing pear.starzinger.net you will see something like this:

Now you just need to add some packages. As an example I will add a couple of packages that I have on my own PEAR channel:

christer@aurora:~$ pirum add /var/www/pear SqlDiff-0.0.3.tgz
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the add command:
INFO   Parsing package 0.0.3 for SqlDiff
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building package SqlDiff
INFO   Building releases
INFO   Building releases for SqlDiff
INFO   Building release 0.0.3 for SqlDiff
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command add run successfully

And then another:

christer@aurora:~$ pirum add /var/www/pear PHP_BitTorrent-0.0.1.tgz
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the add command:
INFO   Parsing package 0.0.3 for SqlDiff
INFO   Parsing package 0.0.1 for PHP_BitTorrent
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building package PHP_BitTorrent
INFO   Building package SqlDiff
INFO   Building releases
INFO   Building releases for PHP_BitTorrent
INFO   Building release 0.0.1 for PHP_BitTorrent
INFO   Building releases for SqlDiff
INFO   Building release 0.0.3 for SqlDiff
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command add run successfully

Now, take a look at the pear channel again in your browser:

The current version of Pirum (1.0.0) does not support anything other than building the channel and adding packages. If you for instance want to remove a package you added by mistake you will need to manually remove files from the get directory in your channel dir, and re-build using pirum. Lets try to remove the PHP_BitTorrent-0.0.1 package:

christer@aurora:~$ cd /var/www/pear/get
christer@aurora:/var/www/pear/get$ rm PHP_BitTorrent-0.0.1.tar PHP_BitTorrent-0.0.1.tgz
christer@aurora:/var/www/pear/get$ pirum build /var/www/pear
Pirum 1.0.0 by Fabien Potencier
Available commands:
pirum build target_dir
pirum add target_dir Pirum-1.0.0.tgz

Running the build command:
INFO   Parsing package 0.0.3 for SqlDiff
INFO   Building channel
INFO   Building maintainers
INFO   Building categories
INFO   Building packages
INFO   Building package SqlDiff
INFO   Building releases
INFO   Building releases for SqlDiff
INFO   Building release 0.0.3 for SqlDiff
INFO   Building index
INFO   Building feed
INFO   Updating PEAR server files
INFO   Command build run successfully

If you take a look at the channel in your browser now you will see that the package has been removed:

The next version of pirum will support removing packages via the pirum command (contributed by yours truly).

And thats that!

Posted in PHP, Technology | Tagged , , | 3 Comments

SqlDiff-0.0.2 released

Just pushed a new version of SqlDiff. The new version supports colors in the output, and the generated statements inserts new columns at the correct positions.

To install simply do:

christer@aurora:~$ sudo pear channel-discover pear.starzinger.net
Adding Channel "pear.starzinger.net" succeeded
Discovery of channel "pear.starzinger.net" succeeded

if you haven’t already added the channel, and then:

christer@aurora:~$ sudo pear install stz/SqlDiff-beta
downloading SqlDiff-0.0.2.tgz ...
Starting to download SqlDiff-0.0.2.tgz (13,038 bytes)
.....done: 13,038 bytes
install ok: channel://pear.starzinger.net/SqlDiff-0.0.2

Read more about SqlDiff on the project page over at github.com.

Posted in PHP | Tagged , , | Leave a comment

SqlDiff-0.0.1 released

Some minutes ago I created the first PEAR package of SqlDiff, a small tool that I have been playing around with some time. The tool is meant to aid people in making sql statements based on the diff of two schemas (for instance in an upgrade scenario where the database schema is updated).

Currently the tool only supports the XML format created by MySQL’s mysqldump (with the -X option). The tool is extensible so if anyone out there wants support for some other database as well, feel free to fork the project and send me a pull request.

More information (installation and usage) can be found on the project page at github: https://github.com/christeredvartsen/sqldiff

Posted in PHP | Tagged , , , , | Leave a comment