Zend Framework and JQuery
I've been using Zend Framework v1.7.0PR to take advantage of the new JQuery support, which can be found under the ZendX (Zend Extras) directory. ZendX_JQuery is a great starting point and makes using JQuery in Zend Framework based applications quick and intuitive.
The ZendX_JQuery component helps set up the JQuery environment, and supports using Google's CDN to load both JQuery, and JQueryUI. In addition, there are a number of view helpers that make autocompletion, datepickers, and other JQueryUI features a breeze.
What currently isn't supported yet, is loading additional JQuery plugins, although it's a breeze to implement since the usage of most plugins is similar to the existing JQuery view helpers.
Print This Post
Dirty Rows and Audit Trails with Zend_Db_Table
There are various ways to update rows in a database table using the Zend_Db_Table components. You can use use Zend_Db_Table::update(), like so:
$table = My_Table();
$table->update(array('age' => 22), 'id = 1');
or retrieve the row, and update it:
$table = My_Table(); $row = $table->find(1)->current(); $row->age = 22; $row->save();
The big difference between the two approaches is that by first retrieving the row, and then updating it, you're actually using three queries. The first one to find the row, the second one to save it, and a third, which is used internally in to Zend_Db_Table_Row_Abstract to refresh data that might have gotten changed due to TIMESTAMP columns, triggers, etc.
If you dig into Zend/Db/Table/Row/Abstract.php, you can see that the class already tracks which columns were changed, so if you only change the value of a single column like the age in the example, not all columns of that row are updated in the database — only those that were actually modified. That's what the protected $_modifiedFields property is for; it records which properties on the Row object were set and only writes those fields to the database. It doesn't, however, check whether the new value is different from the old value.
There's also another protected property, called $_cleanData, which contains the row data as it is currently stored in the database. With that in mind, it is pretty simple to add additional logic to take advantage of that fact.
For instance, we can take it to the next level and only update the record if the column data differs from its previous data. Or perhaps we have a separate audit trail log that needs to capture any column data that was modified.
<?php
require_once 'Zend/Db/Table/Row/Abstract.php';
abstract class My_Db_Table_Row_Abstract extends Zend_Db_Table_Row_Abstract
{
/**
* Returns the values that have *actually* been changed
*
* @return array
*/
public function getDirty()
{
return array_diff_assoc($this->_data, $this->_cleanData);
}
/**
* Whether the record has been modified
*
* @return bool
*/
public function isDirty()
{
return (bool) count($this->getDirty());
}
/**
* Saves the properties to the database.
*
* This performs an intelligent insert/update, and reloads the
* properties with fresh data from the table on success.
*
* Saving will only occur if any column values have been modified
*
* @return mixed The primary key value(s), as an associative array if the
* key is compound, or a scalar if the key is single-column.
*/
public function save()
{
if ($this->isDirty()) {
return parent::save();
}
}
}
I built a feature based on this to record when a row was modified, exactly which columns were updated, when, and by whom, in order to provide a rock-solid audit trail for a web application in a corporate environment.
Print This Post
Zend_Db: Setting MySQL's timezone per connection
I have a Linux server with a system timezone of ET (US/Eastern). But I also have a web application that needs to run in a timezone of PT (US/Pacific). Of course that's not a problem at all. I just set the timezone in my web application's bootstrap:
date_default_timezone_set('America/Los_Angeles'); // Pacific timezone
Now I have another problem; the database. Sometimes I use PHP to generate dates such as date('Y-m-d H:i:s', strtotime('-2 minutes')). Other times I insert records and use new Zend_Db_Expr('NOW()');. But because MySQL isn't aware that I'd like to use pacific time, dates end up being inconsistent and are off by three hour.
It's a fairly easy fix, though, with a bit of logic added to a custom MySQL database adapter:
<?php
/**
* @see Zend_Db_Adapter_Pdo_Mysql
*/
require_once 'Zend/Db/Adapter/Pdo/Mysql.php';
/**
* MySQL PDO adapter extended to set the timezone
*/
class My_Db_Adapter_Pdo_Mysql extends Zend_Db_Adapter_Pdo_Mysql
{
/**
* @var bool
*/
protected $_initialized = false;
/**
* Connects to the database.
*
*/
protected function _connect()
{
parent::_connect();
if (!$this->_initialized) {
$this->_initialized = true;
if ($this->_config['timezone']) {
// Requires PHP 5.2+
$dtz = new DateTimeZone($this->_config['timezone']);
$offset = $dtz->getOffset(new DateTime('NOW')) / 60 / 60;
$this->query(sprintf("SET time_zone = '%d:00'", $offset));
}
}
}
}
To kick this all off my bootstrap contains:
$config = array();
$config['host'] = 'localhost';
$config['username'] = 'username';
$config['password'] = 'password';
$config['dbname'] = 'mydatabase';
$config['timezone'] = 'America/Los_Angeles';
$config['adapterNamespace'] = 'My_Db_Adapter';
$db = Zend_Db::factory('PDO_MYSQL', $config);
Zend_Db_Table::setDefaultAdapter($db);
date_default_timezone_set('America/Los_Angeles');
And now I am free to continue my habit of inconsistency when specifying dates.
Print This Post
The WSDL Blower: The state of SOAP in Zend Framework 1.6
There are all kinds of ways to expose APIs as web services. SOAP, XML-RPC, REST, JSON-RPC. Out of all of these, SOAP is arguably the most complex, but also one of the oldest ways to expose an API (I remember preliminary SOAP and WSDL support in Delphi 6, circa 2001).
Exposing an API as a web service in Zend Framework is fairly straight forward, in fact it is (or should be) as easy as one, two, three:
- Pick your favorite style (Zend_Soap_Server, Zend_XmlRpc_Server, Zend_Rest_Server, Zend_Json_Server).
- Define a properly documented class with the methods and business logic that you want to expose.
- Let your Zend_*_Server::handle(); everything else.
That's pretty much it. Of course each Zend_*_Server has its own settings and options that you can (and sometimes must) configure. XML-RPC is also the only server that supports namespaces.
If you decide on using SOAP, there are a few things to watch out for.
- The WSDL generator doesn't let you set the TargetNamespace attribute explicitly. This becomes an issue when you're working with different environments (development, testing, staging, production, etc.) since the URL of the service determines the namespace. And that makes automatic code generation based on the WSDL problematic. I've contributed a patch to address this, as part of ZF-4117.
- Zend_Soap_Client contains a bug that prevents it from properly proxying method calls. Instead, it'll end up recursing infinitely, or at least 100 times before PHP detects the issue and kills it. The quick fix of removing a single underscore froma method call is outlined in ZF-4152.
- Zend_Soap_Server doesn't properly turn Exceptions into SoapFaults (due to lack of typecasting) as described in ZF-3958. You can still throw SoapFaults explicitly, but that's just bad form since your class shouldn't be SOAP specific. After all, you may decide to also expose it as XML-RPC or what have you, and then the SoapFault, while it might still work properly, is semantically incorrect.
- While Zend_Soap_Server and Zend_Soap_Client are mostly wrappers for the native PHP SoapClient and SoapServer classes, PHP itself lacks WSDL generation which Zend_Soap_AutoDiscovery provides in conjunction with Zend_Soap_Wsdl. Unfortunately the notion of "array of datatype" is not supported, since arrays in PHP are simply declared as "array" and can contain anything. Zend Studio's WSDL generator supports the syntax of "string[]" to specify an array of strings, and this works with complex types as well. "User[]" is an array of User objects. The issue is outlined in ZF-3900, to which I didn't provide one, but two patches, neither of which actually do what I thought they'd do (go me!). However, I have put together an embarrassing hack (Zend_Soap_Wsdl arrayOfType patch) that finally does work — at least for me. So far I haven't worked up the courage to submit it to JIRA. Not one of my finest moments.
I doubt most of these issues will hang around for long, but if you're developing something SOAPy with ZF1.6, you'll like encounter at least one of them.
Print This Post