This is the third installment in my series about writing a RESTful web service in PHP (the previous entries are about understanding the request and routing it. It is probably the last one but there are a few other things I'd like to cover such as error handling, so I might keep adding to it, especially if I get any particular requests or interesting questions in the comments. So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

Output Handlers Instead of Views

We'll have as many output handlers as we have supported output formats. The joy of having all the controllers return the data to index.php is that we can then add common output handling to all the data. In our example system, we can remove that ugly print_r from index.php and instead detect which output format is needed and load the relevant view. My code looks like this:

    $view_name = ucfirst($request->format) . 'View';
    if(class_exists($view_name)) {
        $view = new $view_name();
        $view->render($result);
    }

The most simple example is a JsonView which looks like this:

 
class JsonView extends ApiView {
    public function render($content) {
        header('Content-Type: application/json; charset=utf8');
        echo json_encode($content);
        return true;
    }
}

As you can see here, it's pretty simple! We send the Content-Type header first to let the consumer know what's in the response, then we just encode the JSON and echo it out.
To support other formats, you might loop over your array (remember it might be nested – things usually get recursive at this point for something like an XML format) and transform it into the new format. Between two PHP systems, it might be simpler to support s

Truncated by Planet PHP, read more at the original (another 2815 bytes)

When Noah Sussman asked me to give a Code as Craft Technology Talk last week when I was consulting for Etsy I immediately said yes. However, I was a bit surprised when the talk was announced under the title "An Evening with Sebastian Bergmann". When I read that title the first time, it was just minutes after Arne, Stefan and I had talked about one of our favourite scenes from "A Knight's Tale":

Chaucer: I'm a writer.

Wat: A what?

Chaucer: A wha- a what? A writer. You know, I write, with ink, and parchment. Geoffrey Chaucer's the name, writing's the game. You've probably read my book? The Book of the Duchess? No? Well, it was allegorical.

Roland: Well, we won't hold that against you, that's for every man to decide for himself.

Just like with a talk that I gave last year, I suddenly had a chain of associations in my head that I just had to follow. And down the rabbit hole I went once more ...

Hi! I have no idea why this talk is titled "An Evening with Sebastian Bergmann". I hope that this evening will turn into an interesting discussion about PHPUnit and all things testing. To break the ice, and to not appear completely unprepared, I came up with the following slides ...

So I recently talked with my friends Arne and Stefan about the movie "A Knight's Tale". Somehow the idea stuck in my head that a variation of that title might be a good idea for a talk of mine. After dismissing "A Fool's Tale" I arrived at "A Tool's Tale". So that's what we're stuck with and what I am going to try right now ...

What I just did was a variation on how Geoffrey Chaucer introduces himself in the movie.

Some time in 2001 I started to work on PHPUnit because I wanted to have something like JUnit for PHP. The initial "port" was completed within one weekend. The code was ugly because I had to emulate exceptions which PHP 4 did not have. On November 27th 2001 I checked the code into cvs.php.net.

A lot has changed since 2001. Hopefully not very many developers are still stuck with PHP 4. As of PHPUnit 2.0, which was released on July 14 2004, the day after PHP 5.0.0 was released, PHP 5 is required to run PHPUnit.

PHPUnit is neither the only testing framework nor the only quality assurance tool for PHP. Over the last years a nice ecosystem of static analysis tools started to grow.

I get this question a lot: why do only Germans work on tools that tell me that my code is bad? I do not have an answer for this, sorry. But the statement is also not true: PHP_CodeSniffer is not developed by a German.

PHP has changed and so the have the tools we use to write and maintain code. In 2006 the PHPUnit code was migrated from CVS to Subversion ...

Truncated by Planet PHP, read more at the original (another 3752 bytes)

After hearing about how great PHP Benelux Conferences were I finally made it over to Belgium to check it out, and i was impressed. To catch you up on the new, I moved to Amsterdam last december and thus had the chance of attending the conference which is now 2 hours away on a train ride.

I could not expect less of a wonderful conference when names like Michelangelo van Dam are involved and this was no exception. Its a community conference, planned and organized by community leaders and for community members, this is what makes it so amazing that even without a big name behind it this conference can put up quite a show and bring so many sponsors. As I sat there watching the closing remarks I realized other User Groups and conferences have lots of lessons to pickup from this conference. Let me name a few:

1. Value your sponsors. This was very well executed, during the whole event the sponsors had their logos all over the place and the ones who were present had plenty one on one time with conference attendees. Finally during closing remarks each one was mentioned and with a touch of genius their contributions were described, talk about being thankful.

2. Value your speakers. Who would not want to be a speaker at a conference where you get free belgian beer and chocolates at the end? I know i would, and i'm not even a beer drinker. The amount of care put into the speakers is legendary, pickups, great hotel and i can only imagine what else I did not see myself as a non-speaker.

3. Value your attendees. This should be easy, but lots of conferences fail at it. Good sessions, good venue, good food and infrastructure, just make your client feel confortable. Don't make him want, make everything available to him at the venue and keep him around for more networking and fun.

4. Awesome socials are awesome. The social events around a conference are the crowning jewel to the experience, it allows for much more networking and just plain fun and bonding. This is great for speakers and attendees alike, and is usually the moment where great projects take shape. There is a lot to learn from a chat with Ian Barber about public speaking, he even put it in writing. And there was so much more.

5. Make your attendees pay. Yeah, I said pay. Many conferences think that being "open source" means having a free conference, I say "ppfffff". Charge a reasonable "I'm a beginner developer with low income"-price and put up a great conference using that money, and people will pay. If they do not pay their employers will, if neither of them does, the problem is bigger. Surely the people who will be leaving the conference better then they came in will be willing to pay. This also adds value to the conference, makes it an investment.

6. Value the organizers and your volunteers. There was no single-man effort in the conference, they (from what i saw) worked together like a very well oiled machine. Many times did i see all organizers united discussing something and no man was left trying to solve everything alone. Expand your group, get more people, get volunteer and be sure to thank them, give them their "dues", they will give you their all.

7. Have Fun! Events are always stressful, but you would never guess this from seeing the PHP Benelux crew at work. They just had fun with it, enjoyed, worked, solved solvable problems and apologized for unsolvable ones, what more do we need?

There are probably more lessons to be learnt here, it was a very well executed event, with great speakers, great guests. Coming from Brazil to such a rich network of PHP events is very exciting for me, I love events and now i have multiple large events all around me.

In Belgium I got to see great friends, make new ones, ans most of all realize that it will not be a year before I see them again (yay!). I also picked up quite a few topics to research more and study, as well as being inspired to kickoff new projects and old ideas, the keynotes really did an awesome job to get us inspired.

You can be sure to find me around PHP Benelux 2013, I will be putting out my best to be either a speaker or an attendee, but I'll be there for sure. Congratulations PHP Benelux Crew, it was a wonderful show and a great experience.

© Rafael Dohms for Rafael Dohms, 2012. |

Truncated by Planet PHP, read more at the original (another 1005 bytes)

One of the big features arriving with PHP 5.4 is the addition of a built-in basic webserver for use in development environments. Quite a few of the other scripting languages have something like this so I'm very pleased to see it in PHP. Using a server like this makes it easy to quickly try out some scripts without needing to configure apache or really do anything much! I had to look up a few things to get started, so I thought I'd write them down for posterity.

Get the Server Running

The server runs when you pass the -S switch to PHP on the command line. I had actually compiled PHP 5.4 alongside my existing PHP 5.3 installation, using instructions from an earlier post, and I just specified the full path to the version of PHP I wanted to run). You then supply the server name and port number:

php -S localhost:8080

This gives some initial output, and then information about each request as it comes in:

PHP 5.4.0RC7-dev Development Server started at Sun Jan 29 16:40:49 2012
Listening on localhost:8080
Document root is /home/lorna/test
Press Ctrl-C to quit.
[Sun Jan 29 16:40:55 2012] 127.0.0.1:46713 [200]: /
[Sun Jan 29 16:40:55 2012] 127.0.0.1:46714 [404]: /favicon.ico - No such file or directory

By default, the current directory is your webroot and you can now request whatever files are here, and run PHP in the usual way. You can also edit and save those files and re-request them without restarting the server, just as you would with a normal webserver (something I love about PHP).

The port number can be absolutely anything that you're not already using, I've seen examples with 8080, 8000 and even 1337 - you can use whatever you like. If you pick a port that something else is using, you'll see an error Failed to listen on localhost:8080 (reason: Address already in use)

Changing the DocRoot

If you want to run the server from one place and point it at a document root in another location, simply use the -t flag, followed by the path to the new docroot:

php -S localhost:8080 -t /var/www/awesomecode

Bear in mind that the webserver will run as the user you run this command as, so that user will need to have access to those files. Webservers such as apache often run as other users, but this one will probably run as you.

Routing Requests Like Apache Rewrite

One immediate feature that I was looking for was the ability to redirect all incoming requests to index.php, which I usually do with an .htaccess file. This webserver doesn't support those (although my good friend Josh has created something pretty close) but it does support a routing file. There's a great example in the manual of doing this which I used for reference. You create a file routing.php in the same directory and this becomes your front controller, looking like this:

   if (file_exists(__DIR__ . '/' . $_SERVER['REQUEST_URI'])) {
     return false; // serve the requested resource as-is.
   } else {
     include_once 'index.php';
   }

(this code taken entirely from this internals post as linked from the user contributed notes. It works like a charm but I can't take the credit for it!)

This allows you to serve any files which are access by path in the usual way, but then redirect all other requests through to index.php. It's such a common use case and I'm very pleased so see the examples already in th

Truncated by Planet PHP, read more at the original (another 1355 bytes)

In July 2010 I already blogged about the fact that HipHop for PHP, the source code transformer that turns PHP code into C++ code that can then be compiled with g++, can also be used for static code analysis to find problems in PHP source code.

Today I started to work on a convenience wrapper for HipHop's static analyzer:

➜  ~  hphpa /usr/local/src/code-coverage/PHP
hphpa 1.0.0 by Sebastian Bergmann.

/usr/local/src/code-coverage/PHP/CodeCoverage/Filter.php
  206   TooManyArgument: $this->addFileToWhitelist($file, FALSE)

Of course the tool can also generate an XML logfile in a format that is suitable for continuous integration:

➜  ~  hphpa --checkstyle hphpa.xml --quiet /usr/local/src/code-coverage/PHP
hphpa 1.0.0 by Sebastian Bergmann.

➜  ~  cat hphpa.xml
<checkstyle>
 <file name="/usr/local/src/code-coverage/PHP/CodeCoverage/Filter.php">
  <error line="206"
         message="$this->addFileToWhitelist($file, FALSE)"
         source="TooManyArgument"/>
 </file>
</checkstyle>

Mockery is a simple yet flexible PHP mock object framework for use in unit testing with PHPUnit, PHPSpec or any other testing framework. Its core goal is to offer a framework for creating test doubles like mock objects through the use of a simple and succint API capable of clearly defining all possible object operations and interactions using a human readable Domain Specific Language (DSL). Designed as a drop in alternative to PHPUnit’s phpunit-mock-objects library, Mockery is easy to integrate with PHPUnit and can happily operate alongside phpunit-mock-objects.

Today, I am pleased to announce the release of Mockery 0.7.2, a maintenance release fixing a small number of bugs and annoyances. A special thanks to all those who forked the Github project at and submitted pull requests! Leaving a developer with hardly any work to do other than a quick test and merge is always appreciated! You can install or upgrade to the new version from the survivethedeepend.com PEAR channel.

Another piece of news is that Mockery is now available on Packagist.org for users of Composer. Composer is a tool to help you manage your own projects’ or librarys’ dependencies and it can handle and mix dependencies from Composer compatible repositories like Packagist.org, any git repository using tags, and any PEAR channel. I do this of my own free will and not because Luis Cordova and Benjamin Eberlei are standing behind me with pitchforks .

The more pertinant fixes include:

1. Fixed a problem in resolving methods chains which abuse the Law of Demeter (thanks to the wizardly Robert Basic).
2. Fixed unexpected static calls to an alias mock which were causing fatal errors (thanks to Luis Cordova).
3. Fixed a crash present since PHP 5.3.6 due to a referenced $this variable entering a closure (thanks to Martin Sadovy).
4. Added support for PHP_CodeCoverage 1.1 whose filter class is no longer a singleton (thanks to Matthew Vivian).
5. Added non-halting exception handling (for Mockery exceptions) to the PHPUnit TestListener (thanks to Adrian Slade).
6. Added boolean $prepend (defaults to FALSE) parameter to \Mockery\Loader::register() to allow for registering Mockery’s autoloader to the top of the autoloader stack even after other autoloaders have been registered (thanks to Hermann Kosselowski).
7. Updated documentation/tests for the release of Hamcrest 1.0.0 several days ago (thanks to me, me, me – who finally got to do something nobody else had a pull request for!).
8. Added new \Mockery::self() static method to make retrieving the current mock object simpler and more readable while setting expectations without the need to refer back to past variable assignments.

Users should also note that Hamcrest 1.0.0, which includes a small filename change (hamcrest.php was capitalised to Hamcrest.php), was released several days ago. If you use Hamcrest matchers with Mockery, you should ensure that both libraries are updated on your system.

As always, please report any bugs or potential improvements to the Github issue tracker using the relevant label or, even more appreciated, send me a pull request.