You can find more info at the devzone.

I wanted to add the Zend_Filter_StringTrim filter to all of my text form elements so I decided to just add them on the fly.

Since my forms already extend a custom “MyApp_Form” object (MyApp_Form extend Zend_Form) it was just a matter of intercepting the addElement() method.

So, here it goes, in all its glory:

public function addElement($element, $name = null, $options = null)
{
    parent::addElement($element, $name, $options);

    if (is_null($name)) {
        $name = $element->getName();
    }

    $addedElement = $this->getElement($name);

    if ($addedElement instanceof Zend_Form_Element_Text) {
        if ( ! $addedElement->getFilter('StringTrim') instanceof Zend_Filter_Interface ) {
            $addedElement->addFilter(new Zend_Filter_StringTrim());
        }
    }
}

Since the element is already added to the form using the parent method I didn’t have to check if the element is passed as a string, but does not have a name, or if it’s passed as a Zend_Form_Element object without the name property since the Zend_Form::addElement() already checks for this.

The new autoloader Zend_Loader_Autoloader is just what I was looking for to easily group the forms and models with my application modules. I definitively recommend to read a great article about the new autoloader at Zend Developer Zone.

The whole process of migrating from ZF 1.7.7 was quite painless I just had to replace:

Zend_Loader::registerAutoload();

with

$loader = Zend_Loader_Autoloader::getInstance();
$loader->registerNamespace('MyApp_');

Zend_Log_Writer_Mail is finally in the stable distribution and It took only couple of lines of code to add this to our application logger so now when stuff go terribly wrong I at least know I will be getting an email about it.

You can view the full list of changes in the 1.8 release here.

I look forward to playing with Zend_Navigation and see if we how could we use it to cleanup some of the mumbo-jumbo we are currently doing with ACLs and navigational elements.

Zend_Validate_Db_RecordExists doesn’t look like much, but it makes me happy to remove some custom code because it is now supported in the framework.

Some acctually report big improvements in responsiveness of their applications and increase in number of transactions per second their hardware can handle because require_once() is quite an expensive operation, especially if the required file is already included prior to the call.

If you are wondering how to comment out all the require_once() calls from your Zend Framework without doing it by hand here is the solution. Navigate to the folder where your installation of ZF resides on the server and just enter this into your shell:

find ./ -type f -exec sed -i 's/require_once/\/\/require_once/' {} \;

My box is running PHP 5.2.6 with APC 3.0.19 and Zend Framework 1.7 PR and my include path is optimized for use with ZF. Stripping require_once() calls didn’t make a drastic impact on my setup and average performance gain was around 3 requests per second (from 63 to 66).

Update (May 16, 2009)

Since the release of Zend Framework 1.8 there is a script to strip requre_once calls from ZF in the ZF Performance guide. This script does not remove require_once calls to the new Zend_Loader_Autoloader component.

% cd path/to/ZendFramework/library
% find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' -print0 | \
xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'

Update 2 (October 3, 2010)

Thanks to Tom Anderson for noticing that this does not work since ZF 1.10.8 , the new script for stripping require_once calls is:

% cd path/to/ZendFramework/library
% find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' \
-not -wholename '*/Application.php' -print0 | \
xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'

Note that you must use autoloading if you strip the require_once from the ZF project.

There were also some things I really don’t agree that much. He showed a small PHP frameworks “benchmark” measuring the speed (response time and transactions per second) for each of this frameworks to output the simple HTML page printing out the “Hello world” string. Zend Framework (the framework of my choice) didn’t perform all that bad. Symfony was around 30% slower, and Solar was about 2 times faster. If you are really interested in the numbers have a look at the slides from the session.

The methodology was a little bit questionable. I believe that frameworks offering a caching solution out of the boxes should have been tested with the caching enabled.

Another thing he talked about was removing unnecessary require_once() and include_once() calls from the applications, and their impact on the frameworks speed, and how those calls are handled in PHP internally and how to set up your include path to minimize the impact).

Zend Framework didn’t do that well, as you can see on the graphs plotted out for every framework (dashed lines represent require_once() calls). The main reason for this is I guess that ZF is a loosely coupled framework. The other reason is probably that the ZF is still not mature enough to focus on the optimization issues while there is still so much other work to be done.