In this new post to the Ibuildings blog Stefan Koopmanschap talks about the Dutch PHP TestFest and how it all turned out.

This dutch event, which was sponsored by Ibuildings, was part of the global PHP TestFest initiative, which aims to get a higher test coverage for the PHP language and with that stabilize the language even more - something that will benefit all users of PHP. Back in May, we already deemed our event a big success with 10 attendees, a great presentation by Sebastian Bergmann and a huge number of tests written. But it turns out to be an even bigger success.

Out of the 158 tests written up by the group 39 of them were accepted and are included in the testing suite. As a result, one of the members of the team (Felix de Vliegher) was also given commit rights to the full CVS repository for PHP.

Rob Allen has posted a few notes about the Zend_Cache component of the Zend Framework to his blog today.

Recently I needed to speed up a legacy project that makes a lot of database calls to generate each page. After profiling, I discovered that 90% of the database calls returned data that rarely changed, so decided to cache these calls. One of the nice things about Zend_Framework is that its use-at-will philosophy means that you can use any given component with minimal dependencies on the rest of the framework code.

He shows how, using the Zend_Cache module (and friends Zend_Loader and Zend_Exception), he creates a caching class that can be called anywhere and is used to cache the results from the queries. His default lifetime is set to 7200 seconds - two hours - before the script needs to refresh the cache and get the latest updates.

The PEAR blog has posted the offical results of this year's elections:

Elections are now over and a new PEAR Group has been formed. Just like last year and always following the Constitution, the new members have been elected by a secret ballot of PEAR Developers.

Those elected include Joshua Eichorn, Christian Weiske, Chuck Bugress and Travis Swicegood. This year's President id David Coallier. You can find out more on the PEAR website page for the elections.

On the Internet Super Hero blog, there's a post that looks at how PDO is implemented in PHP and wonders if the PDO::FETCH_UNIQUE constant is broken (as something to fix before even considering the move to PDO2).

I spent quite a lot of time comparing the different behaviours of the various drivers in the hope I could find out how PDO drivers are supposed to work. The PDO documentation and the specification do not cover each and every detail. PDO really needs some love...

He picks out the FETCH_UNIQUE constant as one that needs a little work and tries to track down exactly what it's doing. One issue he found was that it requires combination with other flags to make the unique part of it work correctly (like FETCH_OBJ or FETCH_COLUMN). He works through several examples, both ones that apply the unique call and others that don't, comparing the results.

PHPBuilder is back with part two of their look at creating an online survey (part one is here) and pick up right where they left off:

Last time we set up our form, took the data from that form and emailed it to an email address of our choosing. This time we're going to take the same form data, put it in a database, read the total values and display them on a page.

You'll definitely need to check out part one before you try to tackle this one. They start with the creation of the tables you'll need (with some data to fill it out) and provide the code to handle the results of the submitted survey into those tables. They follow this up with a bit of output - a look at creating the "results" page for the user (or admin...whoever) to see the latest results from the survey's questions.

The PHP-GTK Community website has posted the results of their PHP IDE survey (2007) that's just wrapped up:

Following a two-weeks poll, a first for the community site, the results for the development environment used by PHP-GTK developers are in.

The top three spots on the list were a close run - Eclipse topped the list with 30 percent followed by the generic "simple editors" option at 26 percent and Zend Studio at 25 percent. The rest of the options (well, besides PHPEdit at 4 percent) were at 3 percent or lower in representation. Check out the post for the graph of the outcome and some of their own commentary on the results. Also, check out this page for the full results from the poll.

From the WebDevLogs.com blog today, there's some benchmarking results from Mgcci's look at PHP's methods for grabbing some common data - the script's own name. This includes the "magic" call to __FILE__:

The result shows that __FILE__ is the fastest, so use that when you don't have to use any other method to find the script's self. __FILE__ is a built in constant show the location of the running script.

He gives the benchmark output (time measurement) and includes the code that he used to perform the tests.

Etienne Kneuss has an update on the PHPT Generator project posted to his blog, mentioning specifically how it was used to discover documentation problems in the generated phpt files.

The main use of those phpt files was to have an easy way to check examples used in the documentation. Along with a php script analyzing the results and Hannes' great testing environment, I was able to generate a summary of the examples failing.

The results show that over 50% of the documents passed the test, with the rest split between failing because of missing extensions (9%) and because of an error in the example (41%).

PHPBuilder.com has another in their series of excerpts from the Sams Publishing book "PHP 5 in Practice" today - a look at paginating results on a website.

When creating browse or search functionality on a website, you many find that you end up with more data than the page can easily display at once. In these situations it makes for a better user experience to give users only a certain number of results and then present them with options to see the next and/or previous pages.

The code listing is slightly complex, but it does provide a good, clear look at how to paginate the values in an array. They also explain a bit about the two functions that make it possible - http_build_ query and array_chunk.

On the Synfony project's blog, they've posted about a new testing framework that they've implemented for their framework based around something they call "lime".

If you keep an eye on the timeline, you probably saw that the symfony unit tests have been completely reworked lately. This is because we switched from simpletest, which was fine but had side effects when functional tests were executed all at once, to our own testing framework, lime.

Lime is more lighweight than PHPUnit or simpletest and has several advantages. First, it launches test files in a sandbox to avoid strange effects between each test file run (one of the reasons we were unable to fix the old symfony core tests). It also introduces a new sfBrowser, sfTestBrowser and more importantly sfDomCssSelectorBrowser that allow you to write functionnal tests with ease. It is not backward compatible but is a lot more powerful than the old system. Oh, and it holds in a single file, lime.php, without any dependence.

They show some examples of its usage (and a note on which tests will need to be updated) as well as the output that would come of it. They've also included some sample tests (in the "test/" folder of the release) if you'd like to check it out more throughly.