SELECT count(*) FROM myTableName WHERE someColumn='someValue';

But when you are using a Zend_Db_Table it’s a little confusing how to get the “count(*)” part to work because Zend_Db_Table likes to throw errors saying that it can’t be joined with other tables. So, in your Zend_Db_Table class, here is the syntax you can use:

$sql = $this->select()
       ->from($this, 'COUNT(*)')
       ->where('parent_id=?', $this->id);
echo $this->fetchRow($sql)->num;

//NOTE: $table is an instance of class that extends Zend_Db_Table_Abstract
$data = array('id'=>'', 'color'=>'blue', 'size'=>'large');
$id = $table->insert($data);
echo $id; // --> will print an empty string

If you have to include the name of your primary key column as a key in the array you are tyring to insert, make sure it’s set to null NOT an empty string or zero.

//NOTE: $table is an instance of class that extends Zend_Db_Table_Abstract
$data = array('id'=>null, 'color'=>'blue', 'size'=>'large')'
$id = $table->insert($data);
echo $id; // --> will print the id of the newly inserted row

The reason for this is line 822 in the Zend_Db_Table_Abstract class:

if ($this->_sequence === true && !isset($data[$pkIdentity])) {
  $data[$pkIdentity] = $this->_db->lastInsertId();
}

Notice the isset() condition. If primary key value in the data array you are inserting contains anything other than null then isset() will return true causing the lastInsertId() function to not get called. Hopefully this will clear things up and save us all alot of debugging time!

The lesser known, and much easier, way to redirect within the Zend Framework is to use the Redirector Zend Controller Action Helper

The syntax is much easier since you don’t have to reconstruct a complete url, you just pass in the action and controller names. In fact, the only required parameter is the name of the action. If only an action name is given then the current controller is assumed to be the target controller. Here is a quick example.

_helper->redirector('target', 'example');
    // NOTE: 'example' is optional since the default target controller
    // is the current controller
  }

  public function targetAction() {
    // Do some things...
  }

}
?>

In the action of your Controller, via your Zend Controller Action Helper Broker, call the setNoRender() function of your viewRenderer passing true as the parameter like this:

[php]
require_once('Zend/Controller/Action.php');

class SiteController extends Zend_Controller_Action {

public function indexAction() {
$this->_helper->viewRenderer->setNoRender(true);
echo “Hello World!”;
}
}

?>
[/php]

If you want to disable the View rendering for all of your actions, just call the setNoRender() function in your Controller’s init() function and none of the actions in your controller will render views. If you want to kill the entire idea of automatically rendering views in your application, you can globally disable the viewRenderer by setting the noViewRenderer parameter to true with your Front Controller in your bootstrap file – prior to calling dispatch(). Your code might look like this:

[php]
// This is your bootstrap file:
// Perhaps your index.php file in your public directory

$frontController = Zend_Controller_Front::getInstance();
$frontController->setParam(‘noViewRenderer’, true);

?>
[/php]

I have found CodeIgniter and have now built 3 sites with it. It’s simple, easy to use, speeds up development, has great documentation and, best of all, has won me as a fan. My most recent CodeIgniter project is an educational/e-commerce site about Rebounding with the Cellerciser While developing the site and reading the site content, I was convinced of the many reasons to use a Cellerciser I’ve now been using a Cellerciser for about 3 months and I love this thing!

All this is to say that I’m developing with CodeIgniter now and I’m customizing my development for PHP5. Even though CodeIgniter is not strictly a PHP5 framework (it will run under PHP4 or PHP5) it does try to detect if it’s being run under PHP5 and has several chunksk of PHP5 specific code that get loaded if you are using PHP5. Then, you can code your own models and libraries using strict PHP5 syntax – taking advantage of all the goodness that PHP5 brings to the table.

I took a day or two to look into Kohana which is basically the PHP5 only version of CodeIgniter. Kohana, being pure PHP5, has a few advantages over CodeIgniter. Here is a great reivew comparing Kohana and CodeIgniter In the review there are also a few tips on integrating the Zend Framework in with you CodeIgniter project – a much better use of the Zend Framework than building exclusively upon it.

Even though I exclusively use PHP5 and Kohana takes much better advantage of PHP5 than CodeIgniter does, I ended up sticking with CodeIgniter for the following reasons:

• Better documentation (although Kohana’s is very good too)
• I felt like CodeIgniter had a more secure and substantial user base
• Kohana does not have any unit testing (but it is coming in the next release)
• More add-ons (ignited code) for CodeIgniter adding any “missing” feature you can think of

My biggest complaint with CodeIgniter is the session handling. Session data is stored on the client side in a cookie. So you are limitted to 4kb of data. I prefer to store session data on the server side in a database. There are several add-ons for CodeIgniter that give you server side, database storage for session data.

If you have any questions about CodeIgniter, or comments about CodeIgniter vs Kohana, please feel free to share your thoughts!

The short answer is, you can’t! Unfortunately, this functionality won’t be available until the 1.5 release of the Zend Framework. But you can write your own utitlity function to sort your Rowset for you.

In my project I am working with Patients and their Medications. There is a one to many relationship between patients and medications. One patient can have many medications but a medication belongs to only one patient. I have the following database tables and classes (stripped down for the sake of this example):

[mysql]
CREATE TABLE patients (
id int auto_increment not null,
name varchar(50),
PRIMARY KEY(id)
);

CREATE TABLE medications (
id int auto_increment not null,
patient_id int,
name varchar(50),
PRIMARY KEY(id)
);
[/mysql]

[php]
// file: Patients.php

class Patients extends Zend_Db_Table_Abstract {
protected $_name = “patients”;
protected $_dependentTables = array(“Medications”);
}
[/php]

[php]
// file: Medications.php

class Medications extends Zend_Db_Table_Abstract {
protected $_name = “medications”;
protected $_referenceMap = array(
‘Patient’ => array(
‘columns’=>’patient_id’,
‘refTableClass’=>’Patients’,
‘refColumns’=>’id’
)
)
}
[/php]

Suppose then that you want to get an alphabetical list of all the medications a particular patient is taking. The code looks like this:

[php]
// Make sure your Zend_Db_Table class is loaded
Zend_Loader::loadClass(“Patients”);

// Instantiate your Zend_Db_Table class
$patients = new Patients();

// Select Zend_Db_Table_Row for patient with id of 12
$patient = $patients->find(12)->current();

// Select all of the medications for the patient
$medications = $patient->findDependentRowset(‘Medications’);
[/php]

At this point, $medications now contains a Zend_Db_Table_Rowset that holds a list of Zend_Db_Table_Row objects representing the medications associated with our patient. Suppose now you want to sort the list of medications alphabetically by the name of the medication.

I was irked to learn that there was no way to tell findDependentRowset() to order by one of the selected columns. So I decided to start a Utilities class of static methods that I can use for situation such as this. I wrote the function sortRowsetBy()

[php]
class DU_Utils {

/**
* Sort a Zend_Db_Table_Rowset by the specified column
*
* @param Zend_Db_Table_Rowset – The Rowset to sort
* @param String $colName – The name of the column by which to sort the Rowset
* @return Array – An sorted array of Zend_Db_Table_Row objects
*/
public static function sortRowsetBy($rowSet, $colName, $direction=’desc’) {
foreach($rowSet as $key => $row) {
$rows[] = $row; // Convert Rowset into an array of rows
$vals[$key] = $row->$colName; // Create array out of specified column name
}
// Sort the $rows array based on the $vals array
($direction == “desc”) ? array_multisort($vals, SORT_DESC, $rows) : array_multisort($vals, SORT_ASC, $rows);

return $rows;
}

}
[/php]

The function makes use of a little known PHP function called array_multisort(). This is a peculiar little function to grasp but it’s worth figuring out because of it’s power. There is a good bit of documentation on the PHP website about what the parameters mean and what the function does. In a nutshell, this function sorts one array by another. In our context, the first array is essentially the column you want to sort by and the second array is the table you want to sort. In between the two arrays you can pass some flags to specify how you want to sort the array – ascending or descending – and the type of sort you want to perform – regular, numeric, or string. Note, that both arrays must be the same size in order for array_mulitsort() to do its job.

In conclusion, here is the code to sort our Rowset of medications alphabetically by the name of the medication.

[php]
// Make sure your Zend_Db_Table class is loaded
Zend_Loader::loadClass(“Patients”);

// Instantiate your Zend_Db_Table class
$patients = new Patients();

// Select Zend_Db_Table_Row for patient with id of 12
$patient = $patients->find(12)->current();

// Select all of the medications for the patient
$medications = $patient->findDependentRowset(‘Medications’);

// Sort the medications
$medications = DU_Utils::sortRowsetBy($medications, ‘name’);

// Note that medications is now an array of Zend_Db_Table_Row objects
// not a Zend_Db_Table_Rowset after the sort.

// Loop throught the sort list of medications
foreach($medications as $med) {
// Do something with each medication
print($med->name);
print(“
“);
}
[/php]

1. Create a View Helper
2. Access your Zend_View object from the View Helper (or instantiate a new one)
3. Render a view script from within the View Helper

View Helpers

Zend View Helpers were designed to make it easier to render somewhat complicated output that you might need to repeat multiple times throught your application. The Zend Framework comes with a handful of View Helpers for things like rendering form buttons, form fields, urls, and html lists. The Zend Framework Documentation, however, seems to suggest that View Helpers bundle their application logic with their presentation markup. For example, here is the code from the FormText.php view helper that comes with the Zend Framework.

[php]
public function formText($name, $value = null, $attribs = null)
{
$info = $this->_getInfo($name, $value, $attribs);
extract($info); // name, value, attribs, options, listsep, disable

// build the element
if ($disable) {
// disabled
$xhtml = $this->_hidden($name, $value)
. $this->view->escape($value);
} else {
// enabled
$xhtml = ‘
. ' name="' . $this->view->escape($name) . ‘”‘
. ‘ id=”‘ . $this->view->escape($id) . ‘”‘
. ‘ value=”‘ . $this->view->escape($value) . ‘”‘
. $this->_htmlAttribs($attribs)
. ‘ />’;
}

return $xhtml;
}
[/php]

Notice in the else block how the markup is written out and stored in the $xhtml variable. For simple snippets, this is ok but if you have a complex view that you want to work with then you really need to break the presentation markup out of your View Helper and into a View Script.

Access The View From Your ViewRenderer Or Instantiate A New Zend View

The next thing the View Helper needs is a Zend_View object so that it can render the view script that holds the presentation markup. I chose to reuse the globally available Zend_View by accessing it from the ViewRenderer Helper like this.

[php]
$view = Zend_Controller_Action_HelperBroker::getExistingHelper(‘viewRenderer’)->view;
[/php]

The benefits of reusing the Zend_View that you already have is that you do not have to worry with setting the basepath or the script path. Also, if you have done any customization of your Zend_View then you have access to the customizations from your View Helper. Note, however, that since you are litterally using the same Zend_View in your View Helper as you are using in your Controllers, you need to be mindful of variable clashes since everything is all in the same namespace. For example, if you set

[php]$this->view->someVariable = “some value”;[/php]

in your controller then you have access to this variable in your View Helper and the view script that your View Helper is rendering.

If you prefer to set up a new namespace for your View Helper and it’s view script, you can instantiate a new Zend_View in your View Helper. This also let’s you set up a different directory for storing the view scripts for your View Helper if you so wish. If you want to create a new Zend_View, you can do it like this.

[php]
$config = Zend_Registry::get(‘config’);
$view = new Zend_View();
$view->setScriptPath($config->basepath . “app/views/scripts”);
[/php]

Note that I am storing my basepath in a config file for the sake of portability.

Render A View Script From Your View Helper

The last piece of the puzzle is rendering the markup code that we decoupled from the View Helper logic. The presentation markup for the View Helper is stored in a view script – just like the view scripts for your Controller’s actions. I store the view scripts for my partials in applications app/views/scripts/controllerName directory along with all my other view scripts. If you have a lot of view scripts or partials, feel free to store them in their own directory or however you want to organize them.

I am working on a project that manages medical records. I need to display a list of allergies for each patient in my system. I created a partial to which I pass the patient and the type of allergy list to display – drug allergies or other allergies. So, when all the pieces are put together, the code looks like this:

[php]
/** The View Helper
* file: app/views/helpers/AllergyList.php
*/

class Zend_View_Helper_AllergyList {

public function allergyList($patient, $allergyType) {
$view = Zend_Controller_Action_HelperBroker::getExistingHelper(‘viewRenderer’)->;view;
$view->patient = $patient;
$view->allergyType = $allergyType;
$out = $view->render(“vitalkey/prtlAllergy.phtml”);
return $out;
}
}
[/php]

[php]
/** The View Helper’s View Script
* file: app/views/scripts/vitalkey/prtlAllergy.phtml
*/

patient->getAllergies() as $allergy): ?>
allergy_type == $this->allergyType): ?>

diagnosed_on)): ?>
Diagnosed: diagnosed_on)) ?>

name ?>

//… other code to display allergic reaction details

[/php]

[php]
/** The View Script for the Controller Action
* file: app/views/scripts/vitalkey/patientData.phtml
*/

//… Lots of patient data markup

Drug Allergies

Other Allergies

//… Lots more patient data markup
[/php]

So that is how I handle partials with Zend Framework 1.0.3. Let me know if you have any tips on how to improve any of this. Thanks for reading!mat

Setting Up Exceptions For preDispatch

If your login screen is managed by a different controller, the setup described above is fine. If, however, your login screen is managed by an action in the same controller as the protected actions, you will want to allow unauthenticated access to the login screen. To do this, we need to exclude certain actions from the authentication check. Ruby on Rails let’s you define :except => :actionName to allow certain actions to skip the before_filter. With the Zend Framework, we have to implement that functionality on our own… but it’s easy.

What Action Is Being Called?

To set up your preDispatch function to skip checking to see if a user is logged in for certain actions you need to know which action is being called. You do that like this…

$action = $this->_request->getActionName();

Example Code

Now all you have to do is see if the action that is being called is one of the actions that you want to skip. I set up a private function called verify() to check whether or not the visitor is logged in. If the user is not logged in, I forward them to the loginAction() function. Since an unauthenticated user needs to be able to access the login screeen, we tell the preDispatch() function not to verify visitors requesting the login action. My controller ends up looking someting like this.

class AccountController extends Zend_Controller_Action {

  function preDispatch() {
    // Discover what action is being requested
    $action = $this->_request->getActionName();

    // Create a list of actions which allow unauthenticated access
    $exclusions = array("login");
    if(!in_array($action, $exclusions)) {
      $this->verify();
    }
  }

  /**
   * Check to see if the visitor is logged in. If not, send to loginAction
  */
  private function verifty() {
    $auth = Zend_Auth::getInstance();
    if(!$auth->hasIdentity()) {
      $this->_forward("login");
    }
  }

  function loginAction() {
    // Display your login screen
  }

  // Continue the rest of your class...
}

In the meantime, we have two new products on the website. By popular demand, we now have an amazing set of speakerless noise reduction headphones. We also have a great budget set of noise canceling headphones that are smaller than our premier EX-29 Extreme Isolation Headphones. This makes them great for travel!

$view = new Zend_View();
$view->addHelperPath("DU/View/Helper", "DU_View_Helper");
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer();
$viewRenderer->setView($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);

Put those lines of code in your index.php file somewhere before you call dispatch() on your front controller and all of you view scripts will have access to your own library of View Helpers.

My company’s name is Digital Underware so I have my library set up just like the Zend library in the lib directory of my application. The path to my View Helpers is lib/DU/View/Helper just like the path to the built-in Zend View Helpers is lib/Zend/View/Helper.

If you are interested in seeing a complete example, take a look at this bootstrap file.