Before I continue, I should mention that, not only is it impolite, but quite possibly illegal to take the content of a third party site without the owners permission or knowledge.

To accomplish our task we need some open-source tools:

• Zend Framework (Required)
• Quix (Recommended)
• Dojo Toolkit (Recommended)

Our basic strategy is this:

1. Find a target page with some cool content
2. Find the CSS Selector (or X-path) of the element we want to scrape
3. Verify the selector using Dojo
4. Build a Zend_Service object to fetch the cool content to PHP

Step 1: Finding the cool page

Say I am a developer and I really want to get the outward facing IP of the machine that my PHP script is running on. If there is a router or proxy in between my machine and the Internet, this can be non trivial. As a solution I decide to use the service http://www.whatismyip.com/

Step 2: Finding the CSS3 Selector for the element

Its pretty obvious which element we want to get the selector for. If you are feeling clever you can simply read the code or use a DOM inspector to figure out what the query is on your own. However, selectorgaget.com provides a cool tool that will allow you to point and click to determine the appropraite selector. You can get a bookmarklet directly from their site, or you can get the much more powerful Quix bookmarklet which includes the selectorgaget and a bunch of other cool tools.

If you decided on Quix (I know I did), click on the bookmarklet and enter “sg” in the command box. The selectorgaget should load up and as you move your mouse around the screen it should highlight different DOM nodes. We want the top one, so click on the text “Your IP…” and, checking out the path, we see that it is a rather boring h1.

Step 3: Validation via Dojo

I like to validate the path before taking it over to Zend. I use a Dojo and firebug lite bookmarklet which injects a debugging version of dojo into any page via the AOL CDN. To add this bookmarket drag Inject Dojo into your bookmarks toolbar. In the debugging console that pops up, enter dojo.query(‘h1′); and you should see the h1 DOM element being returned.

Step 4: Moving it all to PHP

Now that we have successfully found our CSS3 selector path, we can move over to PHP and come up with a new Zend_Service component. Our approach will be to extend Zend_Service_Abstract, and implement some custom methods to preform the screen scrape.

The finished class looks like this:

class WhatsMyIpService extends Zend_Service_Abstract
{
	/**
	 * The service endpoint.
	 * This is where Zend_Http_Client will navigate
	 * to fill service requests
	 * @var string
	 */
	protected $_endpoint = 'http://whatismyip.com';
 
	/**
	 * handle to the client
	 * @var Zend_Http_Client
	 */
	protected $_client;
 
	public function __construct()
	{
		$this->_client = self::getHttpClient();
	}
 
	/**
	 * Method to get the external IP of the computer / server
	 * script is running on
	 * @return string
	 */
	public function getMyIp()
	{
		//reset the client parameters, set the URL to whatismyip.com
		//and actually preform the request
		$result = $this->_client
			->resetParameters()
			->setUri($this->_endpoint)
			->request(Zend_Http_Client::GET);
 
		//check to make sure that the result isnt a HTTP error
		if($result->isError()){
			throw new Exception('Client returned error: ' . $result->getMessage());
		}
 
		try{
			//setup the query object with the result body (HTML page)
			$query = new Zend_Dom_Query($result->getBody());
 
			$domCollection = $query->query('h1');
		}catch(Zend_Dom_Exception $e){
			throw new Exception('Error Loading Document: ' . $e);
		}
 
		//check to make sure the query return a result
		if($domCollection->count() == 0){
			throw new Exception('Cannot find DOM Element');
		}
 
		//get the titlestring from the nodevalue
		$titleString = (string) $domCollection->current()->nodeValue;
 
		//now we should have the content of h1 stored in the titleString
		//it should read something like "Your IP Address Is: xxx.xxx.xxx.xxx"
 
		//Now we will parse out the IP address using regular expressions
		if (preg_match('/([\d]{1,3}\.[\d]{1,3}\.[\d]{1,3}\.[\d]{1,3})/', $titleString, $matches)) {
			return $matches[1];
		}else{
			throw new Exception('Unable to parse IP from page');
		}
	}
}

I hope that the script is sufficiently commented, but to summarize:

In the constructor, we get an local instance of a Zend_Http_Client object. Clone() is used to prevent any other Zend_Service objects from polluting our client with their own requests.

In the getMyIp() method, we first setup and preform the request (using the fluid interface provided by Zend_Http_Client). Notice how we reset the parameters: In this case its not actually necessary as we aren’t passing any parameters, but it is good habit to get into in case in the future we expand this class to include GET or POST parameter passing.

Next, we examine what the HTTP client has passed back to us. Hopefully, if nothing has gone wrong, it is a HTML string representation of the page at whatismyip.com. Some basic checks are preformed to ensure that no HTTP errors have occurred, and then we instantiate a Zend_Dom_Query object which provides both CSS and Xpath selectors.

Finally, after running the CSS selector query, we check to ensure we got a DOM element back, get its value and parse out the IP using Regular expressions. Its pretty impressive what can be done in <70 lines of code with the Zend Framework.

To run this class, we could create a directory structure as follows:
library <- Includes Zend framework
WhatsMyIpService.php <- The above class
getIp.php <- php file including the following:

set_include_path(implode(PATH_SEPARATOR, array(
    realpath(dirname(__FILE__) . '/library'),
    get_include_path(),
)));
 
/** Zend_Loader_Autoload **/
require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);
 
$service = new WhatsMyIpService();
echo $service->getMyIp();

The first couple of lines gets the library on the include path, the second block sets up autoloading so we don’t have to manually include files, and the final lines instantiates the class and calls the method.

The Zend Framework based API that I have written duplicates the functionality described on Micheal’s page and exposes the API functionality to PHP applications.

Please keep in mind that as this is an unofficial API, Translink may not want their data being used without their permission. Please contact Translink before making use of this API on a production site.

Example Usage

$translink = new Zext_Service_Translink();
 
//Get the route directions for the 135
$directions = $translink->getRouteDirections('135');
Zend_Debug::dump($directions);
 
//Get the east-bound stops for the 135
$stops = $translink->getRouteStops('135', 'east');
Zend_Debug::dump($stops);
 
//Get the details for an arbitrary stop
Zend_Debug::dump($translink->getStopDetails(51845));
 
//get the latitude and longitude for a stop
Zend_Debug::dump($translink->getStopLocation(51845));
 
//get the stops near a given latitude and longitude
Zend_Debug::dump($translink->getLocationStops(49.25344,-123.167895));

Download & Install

Download the following file:
Zext_Service_Translink
Add it to your library path (same folder that Zend of the Zend framework resides in) if you have autoloading enabled.

I will try to respond to any problems in the comments.

Example Usage

$bclc = new Zext_Service_BCLC();
 
//Get the results of the latest 649 results
$bclc->get649Results();
 
//get the estimated jackpot size for the latest 649 results
$bclc->get649Estimate();
 
//Get the 649 Extra numbers for the latest draw
$bclc->get649ExtraResults()

There are many other functions that the API exposes. Take a look through the source to view them all.

Download & Install

Download the following file:
Zext_Service_BCLC
Add it to your library path (same folder that Zend of the Zend framework resides in) if you have autoloading enabled.

I will try to respond to any problems in the comments.

App_Model_Person:
 tableName: T_person
 columns:
  id: integer
  name: string(64)

People have addresses. One person may have more than one address (billing, mailing, physical, for example). Therefore, we need a second, person address table similar to the following:

App_Model_Person_Address:
 tableName: T_person_address
 package: Person
 columns:
  person_id: integer
  address: string

Notice that the App_Model_Person_Addres model is in the Person package. This is done to ensure that it will be placed in the person subfolder, so the final path of this class will be App/Model/Person/App_Model_Person_Address.php

Before, using the doctrine command line tool to generate the classes, we must make sure that we are going to generate the models in the appropriate location. Assuming that we have an application library on the include path (eg: library/ is on the include path and it has a folder App in it), then we want Doctrine generating the models in the library/App/Model folder. This can be done by setting the models_path to the proper location. Eg:

new Doctrine_Cli(array(
...,
'models_path'         =>  APPLICATION_PATH . '/library/App/Model',
...
));

The main problem with the auto-generated classes produced by the Doctrine_Cli is the filename of the php file that is generated. For, example, the full path of the generated App_Model_Person class will be library/App/Model/App_Model_Person.php; however, according to Zend conventions it should be library/App/Model/Person.php.

The Doctrine Model Autoloader provided below attempts to solve these problems by detecting when a Doctrine Model is being loaded, and then generating the appropriate path (with the full class name acting as the filename). To complicate matters, there are some special cases for base-classes and package classes as well, specifically that they may have Base or Package prefixing the name of the class. The Model autoloader addresses this by detecting the presence of these terms using regular expressions and tweaking the generation of the paths accordingly.

It is very simple to use the Doctrine Model Autoloader class. Simply instantiate it, passing it the prefix of the Doctrine Model namespace. In this case it would be App_Model_. Don’t forget the trailing underscore (“_”), however the class should detect that its missing and add it in for you if you do.

An example usage for the above case would be simply:

$doctrineAutoloader = new Zext_Loader_Autoloader_DoctrineModel('App_Model_');

Upon instantiation, the autoloader registers itself with the Zend_Loader_Autoloader for the passed namepace, so no further setup is required.

<?php
 
class Zext_Loader_Autoloader_DoctrineModel implements Zend_Loader_Autoloader_Interface
{
	/**
	 * The namespace of the models
	 * @var string
	 */
	protected $_namespace;
 
	/**
	 * Whether or not to suppress file not found warnings
     * @var bool
     */
	protected $_suppressNotFoundWarnings = true;
 
	/**
	 * 
	 * @param string $modelNamespace	The namespace of the model to load. Eg: 'Zext_Model_'
	 * @param boolean $quiet			If this is true, suppresses warnings if the file isn't found
	 */
	public function __construct($modelNamespace, $quiet=true)
	{
		if(strrpos($modelNamespace, '_') + 1 != strlen($modelNamespace)){
			$modelNamespace .= '_';
		}
 
		$this->_namespace = $modelNamespace;
		$this->_suppressNotFoundWarnings = $quiet;
 
		$this->init();
	}
 
	/**
	 * Initializes Zend_Loader_Autoloader, pushing the doctrine autoloader onto the autoloading stack
	 * @return void
	 */
	protected function _init()
	{
		$namespaces = array(
			'Package' . $this->_namespace,
			'Base' . $this->_namespace,
			$this->_namespace
		);
 
		$autoloader = Zend_Loader_Autoloader::getInstance();
 
		foreach($namespaces as $namespace){
			$autoloader->pushAutoloader($this, $namespace);
		}
	}
 
	/**
	 * (non-PHPdoc)
	 * @see tests/library/Zend/Loader/Autoloader/Zend_Loader_Autoloader_Interface#autoload($class)
	 */
	public function autoload($className)
	{
		if (class_exists($className, false) || interface_exists($className, false)) {
            return true;
        }
 
 
        //Check to see if we are loading a package / base
        if (preg_match('/(?P<prefix>.+)' . $this->_namespace  . '(?P<class>.+)/mx', $className, $matches)) {
			$result = $matches['prefix'];
			switch(strtolower($matches['prefix'])){
				case 'package':
					$classPath = $this->_loadPackage($matches['class']);
				break;
 
				case 'base':
					$classPath = $this->_loadBase($matches['class']);
				break;
			}
		}else{
			$classPath = $this->_getPath(
				substr($className, 0, strrpos($className, '_') + 1), 
				$className
			);
		}
 
 
		if($this->_suppressNotFoundWarnings){
        	@Zend_Loader::loadFile($classPath, null, true);
		}else{
			Zend_Loader::loadFile($classPath, null, true);
		}
 
        if(!class_exists($className, false) && !interface_exists($className, false)){
        	return false;
        }
 
        return true;
	}
 
	/**
	 * Gets the correct path for loading packages
	 * 
	 * @param $className
	 * @return string
	 */
	protected function _loadPackage($className)
	{
		$package = substr($className, 0, strpos($className, '_'));
 
		return $this->_getPath(
			$this->_namespace . 'packages_' . $package . '_',
			'Package' . $this->_namespace . $className
		);
	}
 
	/**
	 * Gets the correct path for loading bases
	 * 
	 * @param $className
	 * @return string
	 */
	protected function _loadBase($className)
	{
		$package = substr($className, 0, strpos($className, '_'));
 
		return $this->_getPath(
			$this->_namespace . $package . '_generated_',
			'Base' . $this->_namespace . $className
		);
	}
 
	/**
	 * Gets the classpath from an _ separated path and the classname
	 * 
	 * @param string $path
	 * @param string $name
	 * @return string
	 */
	protected function _getPath($path, $name)
	{
		return str_replace('_', DIRECTORY_SEPARATOR, $path) . $name . '.php';
	}
}

Epguides.com is a listing of TV show episode listings. This can be useful, for example, if you are downloading episodes from the internet and want to automatically name the files. Alternatively, if you are hosting a website this API could expose current episode listings for shows of your choice.

The API consists of three parts:

1. Zext_Service_Epguides – The basic service class. Has one public method: getShowObject($showName)
2. Zext_Service_Epguides_Show – The objet that is returned by getShowObject($showName)
3. Zext_Service_Epguides_Episode – Individual episode objects that reside in the show object

Zext_Service_Epguides

Fortunately, Epguides.com has a very regular naming scheme for their pages. The basic pattern is http://epguides.com/{show_name}/ where show_name is the name of the show, in lowercase, with whitespace and special characters removed. This can be accomplished using the following regex:

$showName = strtolower(preg_replace('/[^\w]/', '', $showName));

Rather unfortunately, epguides.com doesn’t follow this naming scheme for all shows. For example, “The Office” (North American Version) is called “office_us”. Therefore, when querying epguides.com using this API you want to be using the string that identifies the proper URL of the desired show. The API will generate the correct URL for shows that conform to the regular naming scheme, but you must use the epguides.com naming conventions for show names that are exceptions to the rules.

After the API generates the URL for a given show, it fetches the corresponding page from Epguides.com and parses it. The parsing is done by a combination of domnode selection using the DOMDocument object and regular expressions. Fell free to read the source for more details.

The parser returns an array which is then passed to the Zext_Service_Epguides_Show() object.

The Show and episode classes are fairly straight forward and mostly act as containers to provide some convenience functions. I hope you can get a fairly good idea of how to work with them by viewing the below usage example.

Example Usage

$epguidesAPI = new Zext_Service_Epguides();
 
//Gets a show object for The Office
$show = $epguidesAPI->getShowObject('office_us');
 
//Print out all the episodes as strings.
foreach($show->getAllEpisodes() as $episode){
	echo $episode . "\n";
}
 
//Get the 10th episode of the 2nd season
$episode = $show->getEpisode(2,10);

Download and Install

Download the following file:
Zext_Service_Epguides
Add it to your library path (same folder that Zend of the Zend framework resides in) if you have autoloading enabled.

I will try to respond to any problems in the comments.

Assuming that you have the standard zend directory structure, you will have something like this:

/application
  /admin
    /controllers
    /layouts
    /views
  /default
    /controllers
    /layouts
    /views
  /feeds
    /controllers
    /views

Or something of the sort. When the user is in the admin section we want to use the layout folder from /admin, and when they are in the default section or in the feeds section of the site we would like to use the layout folder from /default.

We could simply go through all the controllers in the admin section and set the layout path in the init or preDisptach function:

public function preDispatch(){
	Zend_Layout::getMvcInstance()->setLayoutPath('../application/admin/layouts');
}

This may work well for this simple example. However, every time we wish to add a controller to the admin section it would be necessary to setup the layout path and if ever we want to change the layout path for the admin module, there would be a lot of search-replacing.

A Much better solution is to write a plugin for the Zend Front controller. This plugin extends the Zend_Controller_Plugin_Abstract type and will be run each time the front controller is invoked, before anything is rendered.

Our plugin must have some very basic functionality:

1. Ability to register a layout for use with a specified module
2. Ability to fall back to the default layout if there is no layout registered for the current module

The Layout Plugin is as follows:

class Module_LayoutPlugin extends Zend_Controller_Plugin_Abstract {
 
	/**
	 * Array of layout paths associating modules with layouts
	 */
	protected $_moduleLayouts;
 
	/**
	 * Registers a module layout.
	 * This layout will be rendered when the specified module is called.
	 * If there is no layout registered for the current module, the default layout as specified
	 * in Zend_Layout will be rendered
	 * 
	 * @param String $module		The name of the module
	 * @param String $layoutPath	The path to the layout
	 * @param String $layout		The name of the layout to render
	 */
	public function registerModuleLayout($module, $layoutPath, $layout=null){
		$this->_moduleLayouts[$module] = array(
			'layoutPath' => $layoutPath,
			'layout' => $layout
		);
	}
 
	public function preDispatch(Zend_Controller_Request_Abstract $request){
		if(isset($this->_moduleLayouts[$request->getModuleName()])){
			$config = $this->_moduleLayouts[$request->getModuleName()];
 
			$layout = Zend_Layout::getMvcInstance();
			if($layout->getMvcEnabled()){
				$layout->setLayoutPath($config['layoutPath']);
 
				if($config['layout'] !== null){
					$layout->setLayout($config['layout']);
				}
			}
		}
	}
}

The $_moduleLayouts property maintains the mapping between modules and layouts.

The registerModuleLayout function allows us to register a layoutpath and an (optional) layout name for a module.

The actual magic happens in the preDispatch function (which is called by the front controller before dispatching the request). The function checks to see if there is a layout set for the current module; if there is, it switches the layout path to use the module-specific path. Next it checks to see if there is a layout name associated with the layout registered for this module. If there is, it uses it, otherwise it falls back to the default layout name.

In our bootstrapper file (html/index.php) we must setup the default layout and module layout paths and then register the plugin with the front controller. The following code snippit is only a sliver of the bootstrapper and assumes that $controller is an instance of Zend_Controller_Front (eg: $controller = Zend_Controller_Front::getInstance();)

//setup the layout
Zend_Layout::startMvc(array(
    'layoutPath' => '../application/default/layouts',
    'layout' => 'main'
));
 
$layoutModulePlugin = new Module_LayoutPlugin();
$layoutModulePlugin->registerModuleLayout('admin','../application/admin/layouts');
 
$controller->registerPlugin($layoutModulePlugin);

It is important to setup the default layout so the plugin has a layout to fall back to if no module-specific layout is registered.

I hope that this tutorial has served as a quick and easy introduction to Zend Front Controller plugins and module-specific layouts.

From the developers website:

fakemail is a fake mail server that captures emails as files for acceptance testing. This avoids the excessive configuration of setting up a real mail server and trying to extract mail queue content.

I am quite impressed with this handy little script (written in both Python and Perl), as it works exactly as advertised: taking out the time required to properly configure a SMTP server and saving the hassle of having dozens of test messages showered across inboxes. Instead of forwarding emails on to their recipients, it simply saves a raw copy of the email to the specified directory.

The script has a windows installer that bundles the script with python and will run on all flavors of Linux and Unix assuming that they have perl or python installed.

To configure Zend_Mail use fakemail place the following in your bootstrapper or common config file:
[php]Zend_Mail::setDefaultTransport(new Zend_Mail_Transport_Smtp(‘localhost’,array(
‘port’ => 10025
)));[/php]

The ‘localhost’ variable is the address of the computer that fakemail is running on (likely the local machine). The port number is the port that is specified when fakemail is run on the command line.

For more information about fakemail, binaries, and a usage guide. Visit the developers website at Sourceforce: http://www.lastcraft.com/fakemail.php

<IfModule mod_expires.c>
     Header set Cache-Control "max-age=3600, public"
</IfModule>

The above checks to ensure the mod_expires module is loaded in apache, and if it is the Cache is set to expire 3600 seconds from now: 1 hour. Furthermore, the page can be cached in a publicly accessible (shared) cache.

Getting caching working with Zend was a little more challenging. By default Zend (or PHP) writes caching information to headers disabling caching. However, the code snippit below (to be placed inside an Action Controller) blanks out the expires header, sets the cache-control header so that the page expires in one hour, and blanks out the Pragma header.

The expires header allows the server to specify a date when the cache expires (Rather than setting the max-age offset) and the Pragma indicates if the page can be cached in a proxy. I found, with Firefox 3, if Expires and Pragma weren’t blanked out, they would take preference over the Cache-Control header, disabling caching of the page.

$this->getResponse()->setHeader('Expires', '', true);
$this->getResponse()->setHeader('Cache-Control', 'public', true);
$this->getResponse()->setHeader('Cache-Control', 'max-age=3800');
$this->getResponse()->setHeader('Pragma', '', true);

After the addition of caching, the page load was reduced to 8Kb of data pulled down over 9 requests: about a 90% optimization.

I have been using the Dojo toolkit as my Javascript library of choice since back in early 2006 when it was still around version 0.4. Since then, the project has made tremendous strides including the release of version 1.0 and 1.1 with 1.2 on the way. At the beginning of 2008 I started using the Zend Framework to build MVC PHP applications and, with the release of 1.5, it has become my PHP framework of choice.

To my delight, the Zend Framework and Dojo have recently announced a partnership which will lead to tighter integration of these two great open source frameworks.

One of the most exciting additions to the Zend Framework is the Zend_Json_Server support for JSON-RPC. I have been using JSON-RPC with Dojo for quite some time and, up until now, it has been challenging to find a design pattern that plays nice with the Model View Controller implementation in the Zend Framework. However, with the addition of the Zend_Json_Server this is no longer the case.

Prerequisites:

This tutorial assumes you are familiar with developing in PHP and javascript and are experienced with dojo and the Zend Framework using the MVC paradigm.

Common Pitfalls

• Absolute paths are used in the code examples. Ensure that you modify them to reflect your server’s directory structure. This tutorial assumes that you are working with a ZF project whose /html/ directory corresponds to the root of your webserver
• Ensure you place a .htaccess file in /html/scripts/ that disables the re-write engine. If you fail to do this step, when trying to load dojo libraries, ZF will be trying to find controllers that match the requests and throwing exceptions.

Patching Zend Framework

At the time of writing, the Json-RPC component has not been accepted into the Zend Framework (although it will be soon). To get the Zend Framework (ZF) working with Json-RPC we must download code from the incubator area of SVN. If you don’t know how to use a SVN client to check out code, read about it here. Download the current version of ZF and then, using an SVN client, download http://framework.zend.com/svn/framework/standard/incubator/library/Zend/Json/ and place it in the json directory of your local copy of ZF.

Setting up the Directories

For the purpose of this tutorial I will be using code and examples from Nickel: the application that will eventually run SFU Bookswap V.3. I use a fairly standard MVC directory structure as recommended by the ZF docs:

application
	|-default
	|-controllers
	|-views
html
	|-images
	|-scripts
		|-nickel
			|-RPC
library
	|-Nickel
		|-Models
		|-RPC
	|-Zend
		| .... Framework checkout

The reasoning behind placing the Nickel folder in the library is so we can use Zend_Loader to load classes on demand. Also, as a condition of this, the classes in the Nickel folder follow the ZF naming convention: so, say, the class for a book model would be named, Nickel_Model_Book.

Similarly, there is a corresponding directory structure in the scripts folder. This is to be used with the Dojo packaging system. So, to access the RPC handle for the book model we would call a function such as nickel.rpc.book.getAuthor()

Creating the RPC Controller

The next step is to actually create the RPC controller. I have created a file in /application/default/controllers/RpcController.php which contains the RpcController action controller class. RpcController has two actions: one which will return the SMD (simple method declaration) to dojo when the JSON-RPC object is instantiated. The second action, the service action, actually processes the RPC request and returns the result. So, we have:

/application/default/controllers/RpcController.php
[php]_getParam('class');

		$server = new Zend_Json_Server();

		$server->getServiceMap()->setDojoCompatible(true);
		$server->getServiceMap()->setTransport('POST')
       		->setTarget($this->getHelper('url')->url(array('controller'=>'rpc', 'action'=>'service')))
       		->setId($this->getHelper('url')->url(array('controller'=>'rpc', 'action'=>'service'))); 

       	$server->setClass($class);

       	$this->view->data = $server->getServiceMap();
		$this->render('service');
	}

	public function serviceAction(){
		$class = $this->_getParam('class');

		$server = new Zend_Json_Server();
		$server->setClass($class);
		$server->setAutoEmitResponse(true);

		$server->handle();
	}
}[/php]

The smd Action takes ‘class’ as a parameter. This is the name of the class that we wish to expose via Json-RPC, such as Nickel_Rpc_Book. Please note the function call setDojoCompatible(true) which forces the server to generate dojo-compatible SMD definitions. The target function call sets the target of the function calls (the service url) to the service action defined below.

The service action simply processes the RPC request by calling the specified function with the sent parameters.

There is a fairly large security hole opened by this implementation. Since any value can be passed to the ‘class’ argument, it is possible to remotely call functions for any class that can be auto-loaded. A ‘safer’ implementation would simply concatenate the class parameter with “Nickel_Rpc_”. This way is less likely that an attacker could compromise your server by calling a dangerous function.

Writing a RPC Class

Now that we have the RPC server set up we need some classes in Nickel_RPC to call. For the purpose of this example we will use a very simple Book class that has basic functionality:

/library/Nickel/Model/Book.php
[php]getTitle();
	}
	public static function setTitle($bookId, $title){
		$book = new Nickel_Model_Book($bookId);
		$book->setTitle($title);
		$book->update();
		return true;
	}
}
[/php]

In the above RPC class, in addition to the simpleEcho function, we have two static functions: one that reads the title from the Book Model, and the second which writes a new title back to the database via the Book model. Notice that the functions are static: this is because, in the case of our book anyways, a notion of $this doesn’t really make since, as we don’t actually know what book we want the title for unless we pass the book ID from dojo.

Writing the RPC Front-end

Now that we have the backend written, it is fairly quick to write the frontend.

The first step is to create the book rpc file so we can include nickel.rpc.book using a dojo.require statement:

/html/scripts/nickel/RPC/book.js
[js]dojo.provide(‘nickel.rpc.book’);
dojo.require(‘dojo.rpc.JsonService’);

nickel.rpc.book = new dojo.rpc.JsonService(‘/rpc/smd/class/Nickel_RPC_Book’);
[/js]

The above code snippet should be saved as book.js and placed in /html/scripts/nickel/rpc. When this file is included, a new JsonService object is created with functions populated from the SMD generated by the RPC controller class. As a result, nickel.rpc.book will now contain three functions: simpleEcho, getTitle and setTitle.

Using The Front-end.

Finally, we have the opportunity to see the fruit of our labour. Create an indexController and the accompanying view. In the view, after including dojo.js, create a new script block:

/application/default/views/index/index.phtml
...
[js]
...
[/js]

dojo.registerModulePath adds a module path to the dojo loader. This allows us to include our custom nickel modules easily and on-demand.

Conclusion

The Dojo Toolkit and Zend Framework provide a highly structured, maintainable JSON RPC system when used together. This can be used to easily propagate dirty javascript data objects to persistent storage in the backend, as well as expose PHP function calls to javascript to return useful data.

I hope you have enjoyed this tutorial. If you find any typos, mistakes or just wish to leave a message, please add a comment below.

I also encourage you to link to this post if you have found it at all useful in developing your web-application.