Tobias Schlitt, on the heels of the "PHP Eats Rails for Breakfast" posting on Ohloh has helped Sebastian Bergmann get the eZ components project entered into their database for some tracking with some interesting results.

eZ components consists of 171,025 lines of code (including markup and code itself). If you subtract the XML, eZ components consist of 96,424 lines of pure PHP code (no docs included, if I got it correcltly), which is rather much in my eyes.

He gives other stats for the component framework including a price estimate for manhours put into the project and how much, on a per-developer basis, has been contributed to each (including things like a code to documentation ratio and total lines of code contributed).

Tobias Schlitt, on the heels of the "PHP Eats Rails for Breakfast" posting on Ohloh has helped Sebastian Bergmann get the eZ components project entered into their database for some tracking with some interesting results.

eZ components consists of 171,025 lines of code (including markup and code itself). If you subtract the XML, eZ components consist of 96,424 lines of pure PHP code (no docs included, if I got it correcltly), which is rather much in my eyes.

He gives other stats for the component framework including a price estimate for manhours put into the project and how much, on a per-developer basis, has been contributed to each (including things like a code to documentation ratio and total lines of code contributed).

In this new post on Zak Greant's blog, he takes a look at some comments made about the eZ partner program he helped to develop and his responses to clear up some issues.

In a blog post yesterday, CMS expert and Optarian Seth Gottlieb wonders about the eZ partner program.

Gottlieb made comments about it seeming to be a good system, but not quite understanding how it would work when applied. Zak comes back with comments on the reasoning behind the program, how it works to benefit the partner, and how they see those partners, both in giving credit and their involvement with the projects.

For more information on the eZ partner program, check out this page on the eZ website.

In this new post on Zak Greant's blog, he takes a look at some comments made about the eZ partner program he helped to develop and his responses to clear up some issues.

In a blog post yesterday, CMS expert and Optarian Seth Gottlieb wonders about the eZ partner program.

Gottlieb made comments about it seeming to be a good system, but not quite understanding how it would work when applied. Zak comes back with comments on the reasoning behind the program, how it works to benefit the partner, and how they see those partners, both in giving credit and their involvement with the projects.

For more information on the eZ partner program, check out this page on the eZ website.

Ever wondered just how many PHP frameworks there are out there? Well, this mapping of them gives you a good idea. ColdScripts.com has created a single page, digg-ish voting system for lots of the PHP frameworks out there, letting users pick their favorites.

The brighter/clearer the framework's information, the higher it's ranking. To cast a vote, just click on the "+" (plus) in the box for your choice, or the "-" (minus) to detract from the score.

So far, it looks like CakePHP and Symfony are tied in the lead with Code Igniter and eZ Components following close behind. Be sure to head over and vote for your favorite framework today!

Ever wondered just how many PHP frameworks there are out there? Well, this mapping of them gives you a good idea. ColdScripts.com has created a single page, digg-ish voting system for lots of the PHP frameworks out there, letting users pick their favorites.

The brighter/clearer the framework's information, the higher it's ranking. To cast a vote, just click on the "+" (plus) in the box for your choice, or the "-" (minus) to detract from the score.

So far, it looks like CakePHP and Symfony are tied in the lead with Code Igniter and eZ Components following close behind. Be sure to head over and vote for your favorite framework today!

Sebastian Bergmann has posted his own announcement about being accepted as a speaker at this year's Zend/PHP Conference & Expo.

I will present a session titled "Testing PHP Applications with PHPUnit 3" at this year's Zend/PHP Conference. The conference will be held in San Jose, CA, the heart of Silicon Valley, from October 30 to November 2, 2006.

He also notes that this talk will be different from his previos PHPUnit talks with more "real world" examples with the help of the eZ components and Zend frameworks.

Sebastian Bergmann has posted his own announcement about being accepted as a speaker at this year's Zend/PHP Conference & Expo.

I will present a session titled "Testing PHP Applications with PHPUnit 3" at this year's Zend/PHP Conference. The conference will be held in San Jose, CA, the heart of Silicon Valley, from October 30 to November 2, 2006.

He also notes that this talk will be different from his previos PHPUnit talks with more "real world" examples with the help of the eZ components and Zend frameworks.

Derick Rethans talks about something he noticed when working with backwards compatibility to PHP 5.1 for the eZ components project - the first of which is that __get doesn't behave itself in some situations.

The first issue is an extra notice in some cases. In our (ezcMailTools) class we implement a method that allows you to "reply" to a parsed e-mail message. you can see we loop over one of the seemingly public variables of the $mail class. However, the ezcMail class does not have this as a public member variable, but instead uses overload.

This all works 'fine' with PHP 5.1, however with PHP 5.2 the following notice was generated for this code:

Notice: Indirect modification of overloaded property ezcMail::$to has no effect in ../Mail/src/tools.php on line 364

The reason for this is that __get() only returns variables in read mode, while foreach() wants a variable in read/write mode as it tries to modify the internal array pointer. As it can't do this PHP 5.2 will now throw a warning on this.

The mentioned code examples are included and he includes the work-around that he found to help keep the issue from popping up again.

Derick Rethans talks about something he noticed when working with backwards compatibility to PHP 5.1 for the eZ components project - the first of which is that __get doesn't behave itself in some situations.

The first issue is an extra notice in some cases. In our (ezcMailTools) class we implement a method that allows you to "reply" to a parsed e-mail message. you can see we loop over one of the seemingly public variables of the $mail class. However, the ezcMail class does not have this as a public member variable, but instead uses overload.

This all works 'fine' with PHP 5.1, however with PHP 5.2 the following notice was generated for this code:

Notice: Indirect modification of overloaded property ezcMail::$to has no effect in ../Mail/src/tools.php on line 364

The reason for this is that __get() only returns variables in read mode, while foreach() wants a variable in read/write mode as it tries to modify the internal array pointer. As it can't do this PHP 5.2 will now throw a warning on this.

The mentioned code examples are included and he includes the work-around that he found to help keep the issue from popping up again.