The bug I am referring to is caused by most elements that extend the Ext.Sheet component in the framework. This includes select fields, action sheets and date pickers. Once an Ext.Sheet based component has been rendered once the layout will render incorrectly on orientation change. This is a fairly serious issue as it the only way to resolve it at that point is to reload the application.

The problem can be fixed by overriding three different methods as follows:

Ext.override(Ext.Sheet, {
    doHide: function(el, options){
        var parent = this.el.parent();

        this.el.hide();

        if (parent && this.floating && this.modal) {
            parent.unmask();
        }
        if (options && options.fireHideEvent) {
            this.fireEvent('hide', this);
        }

        if (Ext.isObject(el)) {
            if (!(this instanceof Ext.MessageBox)) {
	           this.destroy();
            }
    	}
    }
});

Ext.override(Ext.form.Select, {

    getPicker: function() {
        if (this.picker) {
            this.picker.destroy();
            this.picker = null;
        }
        this.picker = new Ext.Picker({
            slots: [{
                align       : 'center',
                name        : this.name,
                valueField  : this.valueField,
                displayField: this.displayField,
                value       : this.getValue(),
                store       : this.store
            }],
            listeners: {
                change: this.onPickerChange,
                scope: this
            }
        });

        return this.picker;
    }

});

Ext.override(Ext.form.DatePicker, {
    onPickerHide: function(){
        if (this.datePicker){
            this.datePicker.destroy();
            this.datePicker = null;
        }
    }
});

The first of these fixes is courtesy of the sencha touch forum user gcallaghan. Each of these overrides essentially ensures that the instance of the relevent picker is destroyed instead of hidden.

The overhead incurred by recreating the picker/sheet each time is minimal thanks to the speed at which most of the major mobile browsers can manipulate the dom.

The inbuilt autoload function provided by PHP is restrictive. It searches through the defined include_path and if the appropriate file is not found in that directory it throws an error. When you are applying an OOP approach to the development of a system you often end up with a lot of class files. Having all these files in one directory is not a particularly attractive prospect for anyone who likes to keep their code organised.

We can deal with this limitation by providing PHP with a custom autoload function that is capable of scanning particular directories in a recursive manor. This will allow us to organise our code as we see fit. Below is the typical structure I would use for the class files of a website or app I was building:

As you can see the autoload function we need to build must be capable of scanning recursively through all directories within the “inc” directory. Of course, searching through all these directories every time a request is made for a class file would be extremely inefficient. The solution for this is to have the autoloader also maintain a path cache for the class files. This way, when a class is found it can save the full path to the cache and the next time it is requested the search will not be necessary.

Below is the full code for the autoload function we can use to achieve this goal:

function application_autoloader($class) {
	$class = strtolower($class);
	$class_filename = 'class.'.strtolower($class).'.php';
	$class_root = dirname(__FILE__);
	$cache_file = "{$class_root}/cache/classpaths.cache";
	$path_cache = (file_exists($cache_file)) ? unserialize(file_get_contents($cache_file)) : array();
	if (!is_array($path_cache)) { $path_cache = array(); }

	if (array_key_exists($class, $path_cache)) {
		/* Load class using path from cache file (if the file still exists) */
		if (file_exists($path_cache[$class])) { require_once $path_cache[$class]; }

	} else {
		/* Determine the location of the file within the $class_root and, if found, load and cache it */
		$directories = new RecursiveDirectoryIterator($class_root);
		foreach(new RecursiveIteratorIterator($directories) as $file) {
			if (strtolower($file->getFilename()) == $class_filename) {
				$full_path = $file->getRealPath();
				$path_cache[$class] = $full_path;
				require_once $full_path;
				break;
			}
		}	

	}

	$serialized_paths = serialize($path_cache);
	if ($serialized_paths != $path_cache) { file_put_contents($cache_file, $serialized_paths); }
}

spl_autoload_register('application_autoloader');

Before we break this code down to understand more fully what it is doing we should note that this function is located in the “app.intiailise.php” file in the directory structure we looked at earlier. The reason for this is simple. It means we don’t need to explicitly specify the path we wish to use as the class root, we can simply look at the directory the file is in using dirname(__FILE__). Let’s look at the code in a bit more detail.

	$class = strtolower($class);
	$class_filename = 'class.'.strtolower($class).'.php';
	$class_root = dirname(__FILE__);

The function begins by ensuring that the name of the class being called is in lowercase (to ensure no issues with case sensitive operating systems). We then go on to establish that the file we are looking for is called “class.classname.php”. The filename format is dictated by personal preference, it could just as easily be “classname.php” or “classname.class.php” if you change it. The key point to make here is that it must be consistent so the autoloader knows what to look for. Finally we determine the root directory for all the class files which happens to be the location in which this file resides.

	$cache_file = "{$class_root}/cache/classpaths.cache";
	$path_cache = (file_exists($cache_file)) ? unserialize(file_get_contents($cache_file)) : array();
	if (!is_array($path_cache)) { $path_cache = array(); }

Next we focus on initialising the class path cache. The file is held in the cache directory (which is in the same directory as “app.intiialise.php”. The cache itself is held as a serialized array. This means it can easily be saved as a string in a file and converted back into an array again. The code simply fetches the contents of the cache file and unserializes it. There is some work to ensure that the $path_cache variable always holds an array but this should never be the case, it’s just a healthy dose of paranoia.

	if (array_key_exists($class, $path_cache)) {
		/* Load class using path from cache file (if the file still exists) */
		if (file_exists($path_cache[$class])) { require_once $path_cache[$class]; }

	} else {
		/* Determine the location of the file within the $class_root and, if found, load and cache it */
		$directories = new RecursiveDirectoryIterator($class_root);
		foreach(new RecursiveIteratorIterator($directories) as $file) {
			if (strtolower($file->getFilename()) == $class_filename) {
				$full_path = $file->getRealPath();
				$path_cache[$class] = $full_path;
				require_once $full_path;
				break;
			}
		}	

	}

	$serialized_paths = serialize($path_cache);
	if ($serialized_paths != $path_cache) { file_put_contents($cache_file, $serialized_paths); }

This is the meat of the function. We check the $path_cache to check if the file that is being requested has previously been located. If it has we can simply use the path stored in the array to require the file.

If no entry is found in the cache the function goes on to scan the child directories for the requested file. We achieve this by making use of PHP’s inbuilt RecursiveDirectoryIterator and RecursiveIteratorIterator classes.

The combinatation of these classes yields a collection of SPLFileInfo objects which contain details of all the files below the root. Once a match is found for the file that is requested we simply save it to the cache array and require the file. Finally we serialize the path cache once more and save it to the cache file only if changes have been made (this saves a little bit of unnecessary work).

Now that we have created our function we need to tell PHP to use it to autoload the files. We do this like so:

spl_autoload_register('application_autoloader');

The reason we do this instead of just overwriting PHP’s autoload function using __autoload is because spl_autoload_register allows us to stack autoloaders. This means that it will execute each of the autoloaders added to the stack in turn, newest first. If the first fails, it will move on to the second and so on until the stack is exhausted at which point PHP throws an error.

Using this method of autoloading requires that you keep the following things in mind when creating a new class file:

• You must maintain a one class per file policy.
• All your class files must be named with the same structure e.g. “class.classname.php”.

Some last thoughts; you could make this function slightly more efficient still by storing the unserialized cache array in a global store so that it does not need to access the file with each run. There are undoubtedly other optimisations we could make here but I think this is a pretty good starting point.

I have created a simple demo of this concept which you can download and run on your own webserver to try it out yourself. You can download it here. One important thing to note before running the demo; make the “cache” folder writeable by your webserver otherwise it will be unable to create the class path cache. Let me know your thoughts!

If you have any comments, problems or queries about the new design or anything else feel free to get in touch with me.

At the moment I am working through a number of different development, project management and usability books and in coming months you should see a lot of posts here as I talk about my thoughts on these subjects.

I will be looking at a number of design patterns of the coming months but for this post we will focus on the strategy pattern. The strategy pattern employs the principles of polymorphism to help prevent recurring conditionals throughout your code.

I find these patterns are best demonstrated with examples so we will imagine we are developing a system that manages the billing of project work. One of the most common tasks a system like this will be required to carry out is calculate the total price of a project.

If we look at a poorly thought out implementation of this pricing logic we would probably see the following section of code repeated several times throughout the system.

switch ($project->charge_type) {
    case 'fixed_price':
        $price = $project->fixed_price;
    break;
    case 'hourly_rate':
        $price = $total_hours * $hourly_rate;
    break;
}

Conditionals that are replicated many times throughout a system are a typical example of what is known as a code smell. Such code smells are a good indication that you need to re-factor your code. This is where the Strategy pattern comes into play.

The strategy pattern attempts to circumvent one of the most common problems with object oriented systems; the object that knew too much. By separating and encapsulating individual responsibilities within other classes we can keep our objects focused on managing their own section of logic.

A project object, for example, should be concentrating on managing data specific to a project. If we give it responsibility for managing the pricing structures as well then we are starting to increase both the likeliness of bugs and the difficulty of maintenance. The strategy pattern can be used here to separate the pricing logic from the core project object like so:

interface PricingStrategy {
    function price() {}
}

abstract class PriceStrategy implements PricingStrategy {
    function __construct() {}
    function price() {}
}

class FixedPriceStrategy extends PriceStrategy {
    function price() {
        return $fixed_rate_price;
    }
}

class HourlyPriceStrategy extends PriceStrategy {
    function price() {
        return $hours * $hourly_rate;
    }
}

class Project {
   public $pricing_structure;

    function __construct(PriceStrategy $pricing_strategy) {
        $this->pricing_structure = $pricing_strategy;
    }
}

By implementing the PricingStrategy interface each of the pricing objects guarantees support for the price function. As a result the main project object can hold a reference to any of these and call the price function knowing that it will be supported. Now instead of having messy conditionals littered throughout the code a project object can be instantiated by passing any of the chosen pricing structure objects to it’s constructor as follows:

$project = new Project(new FixedPriceStrategy());

echo 'The cost of this project is: '.$project->pricing_structure->Price();

This is of course a very crude and stripped down example but none the less it should demonstrate some of the benefits to this pattern.

• Minimising the replication of conditionals through code will reduce the chances of encountering bugs and make maintenance simpler.
• The design results in simplified client coding meaning other members of the team can easily implement your code in other parts of the system without having to know the inner working of the pricing logic.
• Addition of new pricing strategies becomes a simple matter of adding a new class. Meaning new pricing structures can be integrated more quickly and reliably.

If you want to learn more then the following links will provide you with some more reading:

• Wikipedia’s Strategy Pattern page
• Five Common PHP Design Patterns

Who are you?

My name is Mark Young, I’m a 28 year old web developer who also dabbles in design. I live in a town called St. Helens in England which is roughly between Liverpool and Manchester. For those of you that have the time or inclination you can learn more about me here.

What will you be blogging about?

Well, my area of choice will, for the most part, revolve around web development and design. In terms of development I focus mostly on PHP and MySQL, however, along with front-end development topics like HTML5 and CSS3 I will also touch on some of my other areas of interest (including iPhone development, mobile web apps and heuristics).

What is the reason you are blogging?

I was hesitant for the longest of times to start my own blog because I felt it was a mite narcissistic. What can I offer that isn’t already available on the seemingly infinite number of existing blogs on the same topics? I asked myself.

As time passed I realised that perhaps it could be viewed as more of an exercise in my own personal and professional development. As I work to improve my own skills I can keep track of and discuss them here; Think of this as my own little sandbox. Although I profess to be no master of my craft perhaps anyone reading can learn something through my own experiences at the same time.

As with most blogs you are of course invited to comment on any posts I make using the comment functionality found at the bottom of any article. All friendly discussion and constructive criticism are warmly welcomed.