Web Development and stuff…

I am working on a small API for bluesignal and i wanted a modular architecture. I have done this before using the Zend Framework. But this time i wanted a bit more control while loading the modules. And adding a Bootstrap class would seem like a good option. The only example i could find involved loading all bootstraps on every request. Which doesn’t seem like a good idea. So after reading through the Manual and some blog posts. I decided to give it s shot my self.

The structure i want looks like this.

The application.ini file has the following contents:

includePaths.library = APPLICATION_PATH “/../library”
bootstrap.path = APPLICATION_PATH “/Bootstrap.php”
bootstrap.class = “Bootstrap”
resources.frontController.moduleDirectory = APPLICATION_PATH “/modules”
resources.modules[] = “default”
resources.modules[] = “admin”

includePaths
This sets the applications local library location. Any shared code for this application goes here.

bootstrap.path & class
Define the location and type of the Bootstrap class.

resources
Define the modules location and create a list of modules.

The main Bootstrap class

application/Bootstrap.php

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{

Load the config parameters for this application and set some debugging settings if needed.

    protected function _initConfiguration()
    {
    	$app = $this->getApplication();
    	$config = $app->getOptions();

    	if (APPLICATION_ENV == 'development') {
	    	    error_reporting(E_ALL & E_STRICT);
	    	    if (isset($config['phpsettings'])) {
		    	        foreach ($config['phpsettings'] as $setting => $value) {
		    		        ini_set($setting, $value);
		    	        }
	    	    }
    	}
    }

We need autoloading here because we are using a class from the application library. Right now this causes a problem. A notice is thrown

Warning: include_once(FrontController.php) [function.include-once]: failed to open stream: No such file or directory in Zend/Loader.php on line 147

The application responds fine. And this problem seems to be a recurring issue (ZF-7224, ZF-7550) for the framework. Until now i have not find a graceful fix for this. besides a small patch reversion.

    protected function _initAutoload()
    {
		    $autoloader = Zend_Loader_Autoloader::getInstance();
		    $autoloader->setFallbackAutoloader(true);

		    return $autoloader;
    }

Setup the controller to register the Bluess_Modules_Loader plug-in. And set the prefixDefaultModule parameter so we can prefix the default module controllers as well. Just for the sake of consistency. The Bluess_ namespace is part of my API. And can be changed at will.

   protected function _initController()
    {
    	$this->bootstrap('FrontController');
    	$controller = $this->getResource('FrontController');
       $modules = $controller->getControllerDirectory();
       $controller->setParam('prefixDefaultModule', true);

        $controller->registerPlugin(
               new Bluess_Modules_Loader($modules)
        );

        return $controller;
    }

Now the last method. which is a bit weird. And i am probably missing a key factor here. But if this method resource is not declared only the default module functions. When declared empty all modules function as they should. This would indicate that this method could be used to load the modules. But i haven’t found a way to achieve this yet. Except for loading all modules in a row. Which makes no sense for this purpose. So we leave it empty.

protected function _initModules()
    {
		// Call to prevent ZF from loading all modules
    }

The most important part here is the controller plug-in. This will be the place where module bootstraps are called from.

application/../library/Bluess/Modules/Loader.php

class Bluess_Modules_Loader extends Zend_Controller_Plugin_Abstract
{
	protected $_modules;

Setup the plug-in by passing the applications module list.

	public function __construct(array $modulesList)
	{
		$this->_modules = $modulesList;
	}

The dispatchLoopStartup method will be called on every request and will do the magic. Based on the current module name we create a new Zend_Application with the current modules config file module.ini. And we bootstrap it.

	public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
	{
		$module = $request->getModuleName();

		if (!isset($this->_modules[$module])) {
			throw new Exception("Module does not exist!");
		}

		$bootstrapPath = $this->_modules[$module];

		$bootstrapFile = dirname($bootstrapPath) . '/Bootstrap.php';
        $class         = ucfirst($module) . '_Bootstrap';
        $application   = new Zend_Application(
        	APPLICATION_ENV,
    		APPLICATION_PATH . '/modules/' . $module . '/configs/module.ini'
		);  

        if (Zend_Loader::loadFile('Bootstrap.php', dirname($bootstrapPath))
        	&& class_exists($class)) {
            $bootstrap = new $class($application);
            $bootstrap->bootstrap();
        }
	}
}

Now setup the default module. Once this is done it’s a nice example for further modules. Make sure the module has it’s own layout set.

application/modules/default/configs/module.ini

default.resources.layout.layout = “default”
default.resources.layout.layoutPath = APPLICATION_PATH “/modules/default/layout”

Setup the modules bootstrap and use it to set the modules model location.

application/modules/default/Bootstrap.php

class Default_Bootstrap extends Zend_Application_Module_Bootstrap
{
	protected $_moduleName = 'default';

	protected function _initConfiguration()
    {
		$options = $this->getApplication()->getOptions();

    	set_include_path(implode(PATH_SEPARATOR, array(
		    realpath(APPLICATION_PATH . '/modules/' . $this->_moduleName . '/models'),
		    get_include_path(),
		)));

		return $options;
    }
}

That’s all. Now make sure your layout is set correctly and the controllers are prefixed

application/modules/default/layout/default.phtml

echo $this->layout()->content;

application/modules/default/controllers/IndexController.php

class Default_IndexController extends Zend_Controller_Action
{

It took me a while to get this working like i had it in my mind. But it’s going the right way. If your interested in a working copy. You can download one here.

Last week i had the chance to work with memcache. Something i hadn’t done before. For caching i mostly rely on APC for bytecode. And file based caching for content. Using memecache extension for PHP and de memcached service gives a whole range of features for caching data. And an easy way to manage all this cached data.

The project i am working on is based on Zend Framework. And there for this post will reflect working with memcache in ZF only. With ZF and memcache it’s possible to do frontend and backend caching. I will focuse on the backend side for now. But will setup the frontend as well.

If you don’t have memcache installed do it now. It’s not that hard. On my debian box it went somethign like this:

$ aptitude install memcached
$ aptitude install php5-memcache

Now a days evrything seems to go automatic. So no need to edit the php.ini or anyhting. To check if PHP loaded the memcache extension you can do:

$ php -m | grep memcache
memcache

Memached is automatically started after install. So let’s check if everything went ok.

$ ps -aux | grep memcached
nobody 20965 0.0 0.5 42900 23072 ? S Jan28 0:01 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
root 22393 0.0 0.0 87940 776 pts/0 R+ 12:06 0:00 grep memcached

$ netstat -an | grep 11211
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN

Looking good. Now it’s time to do some configuration in ZF.

First of the frontend settings. With ‘type’ we set the cache method for the frontend. We chose the standard Core class for this. With ‘lifetime’ we set the time for which a cached entity is valid. The ‘cache_id_prefix’ is a nice way to group for instnace cache data by controller. So just give it a name.

cache.frontend.type = Core
cache.frontend.options.lifetime = 600
cache.frontend.options.automatic_serialization = true
cache.frontend.options.cache_id_prefix = [some string]
cache.frontend.options.cache = true

Now it’s the backends turn to get configured. For ‘type’ we choose Memcached. More types are available. For more info read the ZF manual. The rest of the settings are basic memcached settings like host, port and persitance.

cache.backend.type = Memcached
cache.backend.options.servers.1.host = 127.0.0.1
cache.backend.options.servers.1.port = 11211
cache.backend.options.servers.1.persistent = true
cache.backend.options.servers.1.weight = 1
cache.backend.options.servers.1.timeout = 5
cache.backend.options.servers.1.retry_interval = 15

Finally we can do some PHP code. To get the cache instance setup we add a _initCache() method to the bootstrap class. Inside this method we retrieve the config options by calling getOptions(). And setup the cache object. Which is then stored in the Registry for later use.

protected function _initCache()
{
        $options = $this->getOptions();

        if (isset($options['cache'])) {
            $cache = Zend_Cache::factory(
                $options['cache']['frontend']['type'],
                $options['cache']['backend']['type'],
                $options['cache']['frontend']['options'],
                $options['cache']['backend']['options']
            );

            Zend_Registry::set('cache', $cache);
            return $cache;
        }
}

That’s all set. I used the caching for some REST service responses. So i will stick to that in this post as well. The class has a method for adding a cache object.

public function setCache(Zend_Cache_Core $cache) {
    $this->cache = $cache;
}

So fetching the cache instance and passing it to the REST client will look something like this:

$cache = Zend_Registry::get('cache');
$cache->setLifetime(86400);

$client = new Client();
$client->setCache($cache);

The first thing we do inside the calling method is set a unique key for the cache entry.

$cache_id = 'getPage_' . $this->getDomain()
            . $this->getPageName()
            . $this->getCountry();

Then we check if the cache object is set. If that’s the case we check to see if the unique key is already available in the cache.

if (!isset($this->cache) || !($ret = $this->cache->load($cache_id))) {

If a value is returned from the cahce we will return it. If not then we will do the webservice call and store the return data in cache.

 $ret = $this->restClient->call('getPage', array());

if (isset($this->cache)) {
    $this->cache->save($ret, $cache_id);
}

The complete method looks something like this.

protected function getPageFromWebservice()
{
        $cache_id = 'getPage_' . $this->getDomain()
            . $this->getPageName()
            . $this->getCountry();

        if (!isset($this->cache) || !($ret = $this->cache->load($cache_id))) {
            $ret = $this->restClient->call('getPage', array());

            if (isset($this->cache)) {
                $this->cache->save($ret, $cache_id);
            }
        }
        return $ret;
}

That’s all. It’s pretty basic stuff. But so cool!

Two or three weeks ago i was reading post from Bjoern Schotte. That the guys at Mayflower created a poster for Zend Framework. Seems they really love it there. And since i am a big fan myself. I send Bjoern an email to ask for an English version. If available. So some time passed. And i completely forgot about it. Until i came home yesterday and found my own personal copy of the Mayflower Zend Framework poster in the mail.

It’s a cool poster. All the most common used components are there. A nice reference to have. And a great piece of promotion material for the framework it self. Now i just need to find a good spot for it. It will be the second A0 poster hanging here. And probably not the last one. Since mister PHP security himself Stefan Esser from SektionEins is working on a PHP security poster. If you would like your own copy. Send Bjoern an email.

Thanks guys.

Last night i was trying to push a application to my staging environment. When i noticed an error i didn’t had on my local box.

Notice: Zend_Loader::Zend_Loader::registerAutoload is deprecated as of 1.8.0 and will be removed with 2.0.0; use Zend_Loader_Autoloader instead in /path/to/Zend/Loader.php on line 207

A quick check revealed that i had a newer version of the Zend Framework loaded on my staging environment. Locally i have 1.7x and on the staging environment i have 1.8x. And according to the documentation the old Zend_Loader is being deprecated in favor of Zend_Loader_Autoloader.

So in ZF projects prior to version 1.8x when enabling autoloading we would do something like this:

require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();

With the new Zend_Loader_AutoLoader this will look something like this:

require_once 'Zend/Loader/Autoloader.php';
$loader = Zend_Loader_Autoloader::getInstance();
$loader->registerNamespace('Namespace_');

Notice the call to ‘registerNamespace’. This is where you set the namespacing for the classes or application libraries. By default the AutoLoader picks up Zend_ and ZendX_ namespacing. And we can extend this to use our own classes and libraries.

While working on a small project today. I was confronted with a Zend_Db exception that i have seen before. But it still had me searching for a solution. So this time i will write it done for future reference.

I’m working on a small ZF project which uses the MVC structure. And in the Initializer the database connection is setup like this:

public function initDb()
    {
    	$pdoParams = array(
            PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true
        );

        $params = array(
            'host'     => 'localhost',
            'username' => '***********',
            'password' => '***********',
            'dbname'   => '***********',
            'driver_options' => $pdoParams,
        );

        $db = Zend_Db::factory('Pdo_Mysql', $params);
        Zend_Db_Table_Abstract::setDefaultAdapter($db);
        Zend_Registry::set('DB', $db);
    }

So when i first instantiated a connection to the database i was presented a nice error on screen. The stack trace is quiet long. But this is the most relevant part.

exception ‘Zend_Db_Adapter_Exception’ with message ‘SQLSTATE[HY000] [2002] Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2)’

The php bug tracker revealed a nice solution. For some strange reason the PDO extension can’t determine the correct socket while the mysql, mysqli extensions can. This is easily solved in the bootstrap of the project by adding an extra parameter to the config array passed when calling Zend_Db::factory();

$params = array(
            'host'     => 'localhost',
            'username' => '***********',
            'password' => '***********',
            'dbname'   => '***********',
            'driver_options' => $pdoParams,
            'unix_socket' => '/var/run/mysqld/mysqld.sock'
        );

        $db = Zend_Db::factory('Pdo_Mysql', $params);
        Zend_Db_Table_Abstract::setDefaultAdapter($db);
        Zend_Registry::set('DB', $db);

Today i was working with the Zend Framework. And needed the baseUrl to set the correct path for stylesheets and external javascript files. To include stylesheets and javascript files there are methods available in ZF. In your controller you can set:

$this->view->headLink()->appendStylesheet('/css/tester.css');

In your view or layout you can then call

$this->headLink();

This works great. But the current development structure lacks some good rewrite rules. And having the baseUrl is always a good thing. So i did some searching on Google. To figure out if somebody already has a solution for this problem. After a few minutes i found a post written by Yusak Setiawan from zendindonesia (which is defaced by the way) explaining how to add a placeholder in the bootstrap file. Now this is a good solution. But i like to keep my bootstrap file as clean as possible. So i decided to add a Helper that would do the trick.

Create a file called ‘BaseUrl.php’ inside the Helper directory. And fill it with the following code.

class Zend_View_Helper_BaseUrl
{
    function baseUrl()
    {
        $base_url = substr($_SERVER['PHP_SELF'], 0, -9);
        return $base_url;
    }
}

After that it’s extremly easy to get the baseUrl in your views, layouts or controllers.

Inside the view or layout you can call:

$this->baseUrl();

And inside the controller you can call it like this.

$this->view->baseUrl();

Tudor Barbu wrote a great article on this subject.

I decided to give the Zend Framework a try. The first attempt to create a simple SOAP based login.

In the first few hours i had absolutely now problems building my small application. But for some strange reason after a few hours ZF started to throw error’s. Mainly for files it was trying to include. These files were in the correct location. Nothing changed. The include path was still set correctly. I found a few bug reports with similar problems. Although there were some solutions. I was not satisfied with them. And had the feeling the problems were caused by something else.

So after i read threw all code. I notice a few lines i copied from Cal Evans book. These lines mainly set the include_path for the current application. And it looked something like this:

$lib_paths = array();
$lib_paths[] = "/path/to/application";
$lib_paths[] = "/path/to/library";
$inc_path = implode(PATH_SEPARATOR, $lib_paths);
set_include_path($inc_path);

I noticed the application directory was added first. So this is also the first part where PHP starts looking for it’s include files. So i decided to switch them. So the code looks like this now:

$lib_paths = array();
$lib_paths[] = "/path/to/library";
$lib_paths[] = "/path/to/application";
$inc_path = implode(PATH_SEPARATOR, $lib_paths);
set_include_path($inc_path);

After this change the problem seems to have been resolved. I still would like to figure out why ZF has problems with finding it’s own include files. Maybe it’s a combination of the wrong include order and the .htaccess file not working well together.