Table Data Gateway and Row Data Gateway are two design patterns that are very closely related. The former specifies an object that acts as a gateway from our system to a table in a database. This means that it will give us the functionality necessary to execute all common operation to that table easily by providing methods to all the CRUD (Create, Read, Update, Delete) operations.

Row Data Gateway provides very similar functionality, but it lets you execute those operations in a single record of a table.

The Zend implementation

Zend Framework provides us with Zend_Db_Table as an implementation of the Table Data Gateway pattern and Zend_Db_Table_Row as an implementation of the Row Data Gateway pattern. The best way to use these implementations is by extending Zend_Db_Table_Abstract and Zend_Db_Table_Row_Abstract respectively.

When I first read something like “AJAX and Zend Framework” I thought it didn’t make any sense. If AJAX is an HTTP request made by JavaScript then Zend Framework shouldn’t care how the request arrived.

This is kind of true; except when we are using layouts in our views. When we use layouts we don’t just deliver the content of the current action, but also other components that are common among all pages. This is a problem when we want to make an AJAX request that returns a JSON because it would return other pieces of code that would make very difficult to parse the response.

We could create a layout that is specific for AJAX requests that only prints the content of the current action, and that would work correctly. But there is another option that helps us easily switch from different types of replies with little configuration.

Zend Layout

Zend_Layout is the Zend Framework implementation of the composite view design pattern. It allows us to display default content for specific parts of a page (Menu, header, etc), and be able to display specific content for the current action.

In this article we assume the use of Zend_Application, we can check Using Zend_Application for bootstraping if necessary.

To start using Zend_Layout you have to add a line to the application.ini specifying the path of your layouts folder and another line to create a view resource. It should look something like this:

Test Driven Development (TDD) is a software development process that consist in writing unit tests for functionality that is going to be needed and once the test fails writing the code to make it pass. This process is repeated for every new feature or bug.

The most used tool for running unit tests for PHP applications is PHPUnit and is the one we are going to use. We are not going to go through the process of installation in this article.

Organizing tests

We will start by creating a folder for our tests. We probably already have a tests folder in our application root. If we didn’t have it we would have to create it. Inside that folder we are going to create two folders called models and controllers.

Our main suite will allow us to run all our tests with only one command. To create this suite we will create a file TestsSuites.php in our tests folder. This file will allow us to run all our application tests.

Zend_Db_Table is an implementation of the Table Data Gateway design pattern provided by the Zend Framework. It provides a set of methods and attributes useful for interacting with a database table, but can also be extended to provide custom functionality for your application.

In the simplest case you will only want to use the functionality already provided by Zend_Db_Table:

1
2
3
4
5
6
7
8
9
// PDO_MYSQL can be replaced for any of the databases supported by Zend Framework
$db = Zend_Db::factory('PDO_MYSQL', $options);

// Set the db adapter that will be used by default by instances of Zend_Db_Table
Zend_Db_Table::setDefaultAdapter($db);

// Create an instance that will work against a table named 'users'
// This is case sensitive and must match exactly the name of the table
$usersTable = new Zend_Db_Table('users');

Zend_Application is a class that provides an easy to use bootstrapping facility for your application. It also takes care of setting up the PHP environment and introduces autoloading by default.

Zend_Application requires a config file to work, so the first thing we need to do is create it. We will create the configuration file application/configs/application.ini with this content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[production]

; Error reporting
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0

; Paths
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"

[development : production]

; Error reporting
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

This class allows lazy loading of classes upon request. This will in place prevent you from having to manually include the files that you will need in your application.

To use the autoloader you have to first include the file and then create an instance of it. This will usually be done in your bootstrapping class.

1
2
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();

Once your autoloader is ready you can use any class you need without having to manually include the file it belongs to. For example, if after calling autoloader you had this line of code:

1
$frontController = Zend_Controller_Front::getInstance();

Zend framework will replace underscores (_) with directory separators (/) and look for the file Zend/Controller/Front in your include path(get_include_path()), if the file is found it will be loaded, if it is not found an error will be issued.

In most of the Internet applications there is a need to have a configuration file to store static information that the application needs to work. An very common example of this information is credentials to connect to a database.

There are a lot of ways you can store this information and make it accessible to the application. Zend framework includes four classes for parsing four different kind of configuration files: Zend_Config_Ini, Zend_Config_Json, Zend_Config_Xml and Zend_Config_Yaml. In this article we will focus on Zend_Config_Ini for parsing files in the INI format.

When I first saw this programming pattern I found very difficult to understand why would people want to make their code so confusing. When I finally understood why this is used I knew I had to write about it someday. Today is that day.

Self executing functions are useful because using them you avoid creating global variables that could interfere with other parts of your code.

To understand this better I will give three examples of how you pollute and avoid the pollution of the global space.

For the ones of you who didn’t know (I didn’t know either), Apache has a limit on the number of back references you can use when rewriting a URL.

For the people who don’t know I will explain what is a back reference when talking about apache rewrites.

When you do a rewrite of a URL using apache mod_rewrite you translate a URL into an actual resource that apache can find.

For my examples I will use the domain http://ncona.com. If I wanted that the URL http://ncona.com/file loaded the file other_file.html located in my web root I would use a rule like this one:

1
RewriteRule ^file$ /other_file.php

That is a static rewrite but you can also use back reference to make dynamic URLs:

1
RewriteRule ^product/([0-9]+)$ /product_details.php?id=$1