I came across a situation where I had to write a custom class to validate URIs. To write the custom URI validator I made use of Zend_Uri which aids in manipulating and validating Uniform Resource Identifiers (URIs). In particular I used Zend_Uri::check() function to validate the URI in question.

He then goes on to show how he created his validator class and how to use it with Zend_Form.

Edit 15 Apr 2009: Updated link as site has moved.

Migrating an existing PHP application to Zend Framework can be a daunting task, especially if the migration must occur all at once. It is much easier to migrate the application in sections over a longer period of time.

Having not tested his idea yet I can’t say how effective it is but the idea looks good.

echo $this->doctype('XHTML1_STRICT');

The problem is that view helpers will not be aware of this setting and will revert to the default setting HTML4_LOOSE. To avoid this be sure to set the doctype earlier in the bootstrap process, something like so:

$viewRenderer->view->doctype('XHTML1_STRICT');

However, I did find one gotcha that has affected me on my main project at work.

If you happen to have extended Zend_Db_Table_Abstract::_fetch() for some reason or another, be aware that it’s changed in version 1.5.

It was: [php] /** * Support method for fetching rows. * * @param string|array $where OPTIONAL An SQL WHERE clause. * @param string|array $order OPTIONAL An SQL ORDER clause. * @param int $count OPTIONAL An SQL LIMIT count. * @param int $offset OPTIONAL An SQL LIMIT offset. * @return array The row results, in FETCH_ASSOC mode. */ protected function _fetch($where = null, $order = null, $count = null, $offset = null) { // lots of stuff } [/php]

and is now: [php] /** * Support method for fetching rows. * * @param Zend_Db_Table_Select $select query options. * @return array An array containing the row results in FETCH_ASSOC mode. */ protected function _fetch(Zend_Db_Table_Select $select) { // much less stuff } [/php]

Just a heads-up in case someone else has customised this function for their own needs.

Related to this, Ralph Eggert recently discovered something else related 1.5 changes when extending Zend_Db_Table_Abstract and Simon Mundy helped out. The select object that is the parameter to _fetch() has a check in it to prevent you joining to another table. This is because if you join, you break the concept that a Zend_Db_Table represents a single table. However, you can get around it using the function setIntegrityCheck() like this:

[php] protected function _fetch(Zend_Db_Table_Select $select) { // extend select $select->setIntegrityCheck(false); $select->join(// do stuff); } [/php]

The setIntegrityCheck() statement allows you to do a join in the select object and very cleverly puts the table object into read only mode, which is great.

Also, Example 10.136 of the Zend_Db_Table documentation has more information on how to use the $select to get back the data you actually want.

If you are have the incubator in your include path and are playing around with Zend_Form you may get something like the following error…

Zend_Form::__toString() must not throw an exception

…unless you remember to add the incubator view helper path in your controller like so:

$this->view->setHelperPath('/path/to/trunk/incubator/library/Zend/View/Helper/');

The reason being that Zend_Form has a few view helpers that it needs from the incubator.

Otherwise, you can avoid this issue entirely by just using the 1.5.0 Preview Release.

[php] $date = Zend_Date::now(); $diff = $date->sub($birthdate); $diff->toString(); [/php]

Useful tip, that I’ve put here mainly so that I can find it again when I need it!