So I added two more lines in configuration file (/config/config.php).

1
2

$phpmailer_smtpport = 465;
$phpmailer_smtpsecure = 'ssl';

As I added two more setting variables, then they must be used in the class where its taking smtp params. So, I added a small code block in /admin/class.phplistmailer.php.

1
2
3
4
5
6

if ( isset($GLOBALS['phpmailer_smtpport']) ) {
$this->Port = $GLOBALS['phpmailer_smtpport'];
}
if ( isset($GLOBALS['phpmailer_smtpsecure']) ) {
$this->SMTPSecure = $GLOBALS['phpmailer_smtpsecure'];
}

..just above this line

1

$this->Mailer = "smtp";

And I tried again by sending a test email from admin area, but failed.
I again digged into the code to find issue, then I found that phplist uses a very popular & excellent mailer class phpmailer, but they were using quite older version of phpmailer class, so I updated phpmailer class (overwritten all content inside phpmailer folder with new one) with the latest one.

And then it worked like a charm.

You Just require two Js file

<script type="text/javascript"    src="http://code.jquery.com/jquery-1.4.min.js"></script>//Core JQuery Library
<script type="text/javascript"    src="http://static.flowplayer.org/js/tools/1.1.2/all/jquery.tools.min.js?v=1"></script>//For tooltip

You’ll need to have this style for tip

div.tooltip {
background-color:#000;
border:1px solid #fff;
padding:10px 15px;
width:200px;
display:none;
color:#fff;
text-align:left;
font-size:12px;

/* outline radius for mozilla/firefox only */
-moz-box-shadow:0 0 10px #000;
-webkit-box-shadow:0 0 10px #000;
}

HTML code

<form id="myform" action="#">
<h3>Registration Form</h3>
<div id="inputs">
<label for="username">Username</label>
<input id="username" title="Must be at least 8 characters."/><br />
<label for="body">Message</label>
<textarea id="body" title="What's on your mind?"></textarea><br />
<label for="where">Select one</label>
<select id="where" title="Select one of these options">
<option>-- first option --</option>
<option>-- second option --</option>
<option>-- third option --</option>
</select>
<br />
</div>
<label>
I accept the terms and conditions
<input type="checkbox" id="check" title="Required to proceed" />
</label>
<p>
<button type="button" title="This button won't do anything">Proceed</button>
</p>
</form>

Don’t Forget to add below div in body (anywhere)

<div class="tooltip"></div>

And now finally bind your form input elements with ToolTip

<SCRIPT LANGUAGE="JavaScript">
<!--
$(document).ready(function() {
// select all desired input fields and attach tooltips to them
$("#myform :input").tooltip({

// place tooltip on the right edge
position: "center right",

// a little tweaking of the position
offset: [-2, 10],

// use the built-in fadeIn/fadeOut effect
effect: "fade",
// custom opacity setting
opacity: 0.7,
// use this single tooltip element
tip: '.tooltip'
});
});
//-->
</SCRIPT>

Now click on any of input box from your form.

Note I was using windows machine & accessing code base on a linux machine in my local network using Samba Share

I found an option ‘export’ in svn client (Tortoise SVN), which export all the code quite well, so I thought I got the solution, but problem came when I couldn’t get svn ignored files in the exported code & above all I can’t see the ignored icon on the file/folder because my codebase was on some other machine in my local network (LAN). And folder structure of my codebas was too complex & big to find svn ignored files/folders.

So I just written a simple php script to browse all files & folders recursively & delete all the svn related files & folders from the code base.

NOTE: Please take a backup of all your code before executing this script, else you may loss your code.

<?php

$Src = "/var/www/html/project/";//put forward slash at end of path

function DeleteRecursive($Dir) {

    if (is_dir($Dir))
    {
        $handle=opendir($Dir);
        while ($file = readdir($handle))
        {
            if(is_dir($Dir.$file) && $file!="." && $file!="..") {

                 if($file == ".svn") {
                     RD($Dir.$file."/");
                 }
                 else {
                     DeleteRecursive($Dir.$file."/");
                 }
             }
        }
        closedir($handle);
    }
    else {
        echo "Directory:<b>$Dir</b> doesn't exist";
        exit();
    }
}

function RD($Dir) {

    if (is_dir($Dir))
    {
        $handle=opendir($Dir);

        while ($file = readdir($handle))
        {
            if(is_dir($Dir.$file) && $file!="." && $file!="..") {
                RD($Dir.$file."/");
            }

            elseif($file!="." && $file!="..") {
                echo "DELETING FILE:".$Dir.$file."<br>";
                unlink($Dir.$file);
            }

        }
        closedir($handle);
        echo "DELETING DIR:".$Dir."<br>";
        rmdir($Dir);
    }
    else {
        echo "Directory:<b>$Dir</b> doesn't exist";
        exit();
    }
}

echo "Deleting All SVN related Files & Folders from the directory - <b>$Src</b> (Including Sub-Directories)<br>";
DeleteRecursive($Src);
?>

Your comments & suggestion are welcome

Happy Reading

<HTML>
<HEAD>
<SCRIPT language=”javascript”>
function _allowNumeric(e)
{
var keyp;
keyp = getKeyCode(e);

if(keyp >= 48 && keyp <= 57)
{
return true;
}
else if(keyp == null)
{
return true;
}
else
{
if(keyp == 8 || keyp == 0)
{
return true;
}
else
{
return false;
}
}
};

function getKeyCode(e)
{
if (window.event)
{
return window.event.keyCode;
}
else if (e)
{
return e.which;
}
else
{
return null;
}
};

</SCRIPT>
</HEAD>
<BODY>
Type your phone number : <INPUT TYPE=”text” onKeyPress=”javascript: return _allowNumeric(event);” onpaste=”return false;” />
</BODY>
</HTML>
<!– hope this help you –>

A normal sql select query performs case-insensitive query which means if the user name is raj,Raj,RAJ then it will select all users using simple select. Below query is a normal mysql select query -

SELECT * FROM tablename WHERE username=’raj’

But if you want a query to be case sensitive then you can use following query-

SELECT * FROM tablename WHERE BINARY username =’raj’

this will select only those user that exactly matches with user name raj and not Raj and RAJ.

Hope this will help you – Enjoy !!

The scenario was, suppose there’s a table called ‘employees’ with structure like this;

CREATE TABLE `employee` (
`emp_id` int(11) NOT NULL auto_increment,
`designation` varchar(15) NOT NULL,
PRIMARY KEY (`emp_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

And after populating the records it looks like this

And here’s the desired output; All the MANAGERs on top of the list, then all PMs, then all TLs, then SSEs… and so on. i.e the order is non-alphabetic.

Here’s the solution for this.

SELECT
`emp_id`,
`designation`,
CASE `designation`
WHEN “MANAGER” THEN 1
WHEN “PM” THEN 2
WHEN “TL” THEN 3
WHEN “SSE” THEN 4
WHEN “SE” THEN 5
WHEN “DESIGNER” THEN 6
END AS level
FROM
`employee`
ORDER BY
level

And to change order of levels, we just need to change the designation corresponding numeric values in CASE.

NOTE: Please replace ” with single quotes in the above query to run.

Enjoy!

This was my thought, I’ll appreciate your thoughts, comments & suggestions.

Lazy initialization is the tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.

In a software design pattern view, lazy initialization is often used together with a factory method pattern. This combines three ideas:

• using a factory method to get instances of a class (factory method pattern)
• storing the instances in a map, so you get the same instance the next time you ask for an instance with same parameter (compare with a singleton pattern)
• using lazy initialization to instantiate the object the first time it is requested (lazy initialization pattern).

A Simple PHP Example

class User{

    protected $_id;

    public function getId(){

        return $this->_id;
    }
}

class Post{

    protected $_userId;

    protected $_text;

    /**** @var User*/
    protected $_user;

    public function setUser(User $user){

        $this->_userId = $user->getId();

        $this->_user = $user;
    }
    public function getUser(){

        if (!$this->_user) {

            $this->_user = new User($this->_userId);

        }
        return $this->_user;
    }

    public function setText($text){

        $this->_text = $text;
    }

    public function getText(){

        return $this->_text;
    }
}

A PHP 5 Example

class View{

    protected $_values = array();

    public function set($name, $value){

        $this->_values[$name] = $value;

    }

    public function render($file){

        extract($this->_values);

        ob_start();   include($file);

        return ob_get_clean();
    }
}

class Page{

    /*** View object.** @var View*/

    protected $_view;

    public function __construct(){

        // remove attribute to use the __get magic method in first access

        unset($this->_view);
    }

    public function __get($name){

        if ($name == '_view') {       // load view object

            $this->_view = new View();

            return $this->_view;
        }
    }

    public function actionIndex(){

        $this->_view->set('title', 'Lazy Initialization');

        print $this->_view->render('lazy.tpl');
    }
}

The Singleton is one of the simplest Patterns to understand. It’s common usage is to ensure that only one instance of a class is ever instantiated. The reason for wanting such behaviour varies but typically it is because only one object instantiated from the source class is required and you want the resulting object to be available throughout an application, i.e. globally available.

An example might be a class for storing Settings. A Settings class is a good candidate for a Singleton because its data is immutable (the only way to change settings data is to edit the settings file) and it is likely required in many areas of an application. Furthermore creating a new Settings object wherever it is needed is wasteful of resources – each is identical to all others.

Definition

Definition: The Singleton Pattern proposes a static method for creating an instance of a class in such a way that once instantiated further calls to the same static method return a reference to the original instantiated object.

A PHP 5 Example

An example for PHP5 (without specific Settings methods implemented):

class Settings {

private $settings = array();

private static $_instance = null;

private function __construct() {
// private constructor restricts instantiaton to getInstance()
}

protected function __clone() {
// restricts cloning of the object
}

static public function getInstance() {
if(is_null(self::$_instance))
{
    self::$_instance = new self();
}
return self::$_instance;
}

public function import() {
// ...
}

public function get() {
// ...
}

}

Implementing the Singleton Pattern

The key to implementing a Singleton is utilising a static variable; a variable whose value remains constant even when execution leaves its variable scope. This stores the object originally instantiated between calls to the static method Settings::getInstance(), and returns a reference to it on each subsequent call to the method.

Also note that the constructor is usually made private. To ensure only one Settings object is ever used, we should restrict access to the constructor to prevent a new object being created in error. This specific restriction is not possible in PHP 4 so bear this in mind.

The Singleton also requires careful consideration before use. It is by nature very similar to a global variable – the static method is available from anywhere in the application once the file containing the class is included. This can create problems similar to those experienced with global variables – and so should be used with some degree of care. The near global nature of the Singleton has led to it being referred to on occassion as an “Anti Pattern” since it is easily misused as an alternative to making data global.

Using a Singleton is as simple as calling its static getInstance() method.

// fetch settings from INI file
$settings = Settings::getInstance();
$settings->import('/app/settings.ini');

// we can now use the Settings object somewhere else, e.g. database class
class DB_Abstraction_MYSQLI {

private $settings = null;

public function __construct() {
// Settings already exists with imported settings data
// Fetch pre-existing object via Singleton method
$this->settings = Settings::getInstance();
}

public function connect() {
$conn = mysqli_connect(
    $this->settings->get('db.host'),
    $this->settings->get('db.username'),
    $this->settings->get('db.password'),
    $this->settings->get('db.database')
);
return $conn;
}

// ...

}

The alternative to using the Singleton is of course to instantiate a Settings object, and import the settings INI file again. However doing so only wastes resources since the data is immutable and identical to that held in all such objects. Why have a dozen identical Settings objects when you only need one?

Disadvantages

The Singleton is not without its disadvantages. We have already noted that its global nature can cause problems similar to using global variables and encourage misuse without care. It can also make the practice of Unit Testing more difficult. Unit Testing typically tests individual objects. In testing the DB_Abstraction class above, a programmer may wish to “mock” the Settings object (i.e. insert a fake object with known return values). This is useful in cases where the Settings class may not even yet exist, and we need to emulate it.

One solution, is to amend the class so that a developer may optionally pass a Settings object as a paramater into the constructor. The code for this may look similar to:

class DB_Abstraction_MYSQLI {

// ...

public function __construct($settings=null) {
$this->settings = is_null($settings) ? Settings::getInstance() : $settings;
}

// ...

}

This allows more flexible testing since a developer can optionally override the default behaviour of using the Settings class Singleton method, and replace it with any arbitrary Settings object they choose to facilitate testing.

Singletons for PHP 4

PHP 4 does not support static properties/variables in classes. As a result the method of implementing Singletons differ slightly. Rather than use a class property, we instead use a static variable from within the Singleton getInstance() method. In addition, PHP 4 does not support access keywords for class properties or methods. This means that PHP 4 constructors will always be available in addition to the Singleton method of instantiation.

An example of a PHP 4 Singleton implementation follows:

class Settings (

$settings = array();

function Settings() {
// no support for "private" keyword
}

function &getInstance() {
static $thisInstance;
if(!isset($thisInstance[0]))
{
    $thisInstance = array();
    $thisInstance[0] =& new Settings();
}
return $thisInstance[0];
}

function import() {
// ...
}

function get() {
// ...
}

}

You can retrieve the instance with

mySettings =& Settings::getInstance();

Other version

class MyClassUsedAsSingleton
{
var $_value;

function MyClassUsedAsSingleton ($directCall=true)
{
if ($directCall) {
    trigger_error("MyClassUsedAsSingleton is singleton!", E_USER_ERROR);
}
}

function &getInstance()
{
static $instance;
if (!is_object($instance)) {
    $instance = new MyClassUsedAsSingleton(false);
}
return $instance;
}

function set($value)
{
$this->_value = $value;
}

function get()
{
return $this->_value;
}

function isDefined()
{
if (is_null($this->_value)) {
    return false;
}
return true;
}
}
// static access
function setValue($value)
{
$object =& MyClassUsedAsSingleton::getInstance();
$object->set($value);
}

function getValue()
{
$object =& MyClassUsedAsSingleton::getInstance();
return $object->get();
}

function isValueDefined()
{
$object =& MyClassUsedAsSingleton::getInstance();
return $object->isDefined();
}
// use
function changeValue()
{
setValue("New Value");
}

if (!isValueDefined()) {
setValue("Default Value");
}
echo getValue();
changeValue();
echo getValue();

Note: Due to the way in which PHP 4 implements static variables, a static variable cannot hold a reference to a value throughout execution. However a static variable array element can. See References with global and static variables for more information.

Singleton Function

Another way to get a singleton of a class, without actually adding any additional code to the class is to use a function that will return or make a new instance of said class.

function singleton($class)
{
// Static Array Holding All Instances of Singleton Classes
static $Instances = array();
if(!isset($Instances[$class])){
$Instances[$class] = new $class();
}
return $Instances[$class];
}

Conclusion

Singletons as we have seen are a useful Design Pattern when used with care. They allow a single instance of any object to be globally available within an application. Implementation is possible in all current PHP versions, although constructor restriction is not possible in PHP 4. We have also covered how the Pattern can pose problems when unit testing, and how to overcome these with some small amendments (what some people like to call “loose wiring”).

The Singleton is not the only method for sharing objects across an application. Two other useful Patterns to examine are the Registry and ServiceLocator. Another method coming into popular discussion in PHP forums is Dependency Injection.

The intuitive naming of Patterns gives a clue as to the meaning of a Transfer Object. In short a Transfer Object bundles data into a single, easy to transport object. The Transfer Object can sometimes be referred to as the Data Transfer Object (as in POEAA). Both names refer to the same Design Pattern.

There are a number of reasons why a Transfer Object is useful. By grouping related sets of data in a single object, it reduces the complexity of passing such data into methods by removing long parameter lists. Long parameter lists are often termed a “code smell” since they can be confusing and parameter order must be maintained even if a value is not used. As a return value from a method, a Transfer Object also enables multiple values be returned.

Of course this can be easily accomplished in PHP by an array. While a Transfer Object may resemble an array, it has other features that ultimately make it more useful:

• A Transfer Object has a class type which can help enforce an interface by using PHP5′s Type Hinting.
• It’s preset properties will always be available (with default values). One can even prevent the setting of new public properties.
• It is possible to perform additional actions in a Transfer Object upon setting a new value via PHP5′s Magic Methods.

Definition

Definition: The Transfer Object allows the encapsulation of multiple known values in a single object that supports basic data storage and retrieval functionality.

Implementation for PHP5

Implementing a Transfer Object is quite simple. A distinction should however be made between a Transfer Object and the very similar Value Object. The values in a Transfer Object are not immutable, i.e. they can be changed via a public interface (getters and setters) or by defining the Transfer Object’s properties as public or using Magic Methods to simulate public properties in the interface. Often the two Pattern titles are used interchangeably although there are differences in their respective goals.

An example of a Transfer Object might be an object which stores the data associated with a row in a database table. Rather than passing each database value individually to other objects’ methods, one need only pass the representative Transfer Object. This simplifies operations quite a bit and removes a lot of complexity from a class interface if used wisely.

Moreover, since a Transfer Object has a specific class type. An accepting method can restrict a parameter to only accept the expected Transfer Object by using Type Hinting.

A simple PHP5 Transfer Object:

class User_Row {

    public $user_name = '';
    public $user_password = '';
    public $user_email = '';
    public $user_url = '';

    public function __construct($name='', $password='', $email='', $url='') {

        $this->user_name = $name;
        $this->user_password = $password;
        $this->user_email = $email;
        $this->user_url = $url;
    }
}

Note that the properties are defined as public. For this Transfer Object, the client code can use the properties directly without accessors. Since a Transfer Object by definition is not designed to hold arbirary properties (created by client code), the Registry Pattern is more suited for such a purpose or one can even fall back on an array. While a Registry is agnostic to its contents, a Transfer Object’s property names (or alternatively the matching setters/getters) form part of its testable interface.

A Unit Test (using SimpleTest) for the above simple Transfer Object would contain:

class TestUserRowSimple extends UnitTestCase {

    public function testConstructor() {

        $row = new User_Row('name', 'password', 'email', 'website');
        $this->assertEqual($row->user_name, 'name');
        $this->assertEqual($row->user_password, 'password');
        $this->assertEqual($row->user_email, 'email');
        $this->assertEqual($row->user_url, 'website');
    }

    public function testPublicProperties() {

        $row = new User_Row;
        $row->user_name = 'name';
        $row->user_password = 'password';
        $row->user_email = 'email';
        $row->user_url = 'website';
        $this->assertEqual($row->user_name, 'name');
        $this->assertEqual($row->user_password, 'password');
        $this->assertEqual($row->user_email, 'email');
        $this->assertEqual($row->user_url, 'website');
    }
}

It’s worth noting that the most common alternative to a Transfer Object is a simple array. An array and a simple Transfer Object share similar characteristics. A Transfer Object however has a class type and will always contain specific properties (optionally with default values). Additionally a Transfer Object can perform it’s own private internal operations on incoming and outgoing data by using the PHP5 Magic Methods: __set() and __call() to overload the public properties.

Let’s consider our previous User Row example. As the User Row Transfer object is passed around our application and other classes may alter the original data. This changed data will need to be stored to the database. To prevent unnecessary SQL update operations, we would like if the Transfer Object could inform the application whether it’s data has been changed (i.e. dirty) or unchanged (i.e. clean).

For the example below we’ll make use of PHP5′s Magic Methods in order to control the value of an additional private property – isDirty. Other objects will be able to retrieve the value of isDirty by calling the isDirty() method.

User_row.php

class User_Row {

    private $data = array('user_name' => '','user_password' => '', 'user_email' => '', 'user_url' => '');
    private $isDirty = false;

    public function __construct($name='', $password='', $email='', $url='') {

        $this->data['user_name'] = $name;
        $this->data['user_password'] = $password;
        $this->data['user_email'] = $email;
        $this->data['user_url'] = $url;
    }

    public function __get($name){

        if (isset($this->data[$name])) {

            return $this->data[$name];
        }
    }

    public function __set($name, $value){

        if (isset($this->data[$name])) {

            $this->data[$name] = $value;
            if($this->isDirty === false) {

                $this->isDirty = true;
            }
        }
    }

    public function __isset($name) {

        return isset($this->data[$name]);
    }

    public function __unset($name) {

        unset($this->data[$name]);
    }

    public function isDirty() {

        return $this->isDirty;
    }
}

The differences from our simple prior example are not all that complex assuming you are familiar with PHP5′s overloading[1] magic methods. The use of the Magic Methods sets up access to private member properties (the private $data array) while upholding the interface that properties are publicly accessible.

Overloading with magic methods lets us use the class in the same way as the first example only this time the Transfer Object can check whether it’s default values have changed by setting the value of the isDirty property to TRUE. There are no public properties since magic functions cannot overload a property which is already defined – hence they are moved to a private array. As a last step we add a public getter method to retrieve the isDirty value.

The use of magic methods which rely solely on a defined private array of possible values also has an additional effect: it prevents the setting of any new public properties by client code. In effect the magic methods version is limited to the defined properties – no new ones can be set.

In both cases, the classes can be used in the following way.

require 'User_Row.php';
$row = new User_Row('Padraic', 'mypassword', 'myemail', 'mywebsite');

// test output
echo $row->user_name, PHP_EOL;
echo $row->user_password, PHP_EOL;
echo $row->user_email, PHP_EOL;
echo $row->user_url, PHP_EOL;

Output:

Padraic mypassword myemail mywebsite

As with our simple Transfer Object, we can verify that the complex version follows an identical interface as the simple version by writing a Unit Test to verify the expected behaviour of the class. The Unit Test is identical to the last version, except that we additionally ensure the isDirty property value is set to TRUE when a value is changed from the defaults (set via the constructor when a User_Row object is instantiated.

class TestUserRowComplex extends UnitTestCase {

    public function testConstructor() {

        $row = new User_Row('name', 'password', 'email', 'website');
        $this->assertEqual($row->user_name, 'name');
        $this->assertEqual($row->user_password, 'password');
        $this->assertEqual($row->user_email, 'email');
        $this->assertEqual($row->user_url, 'website');
    }

    // public properties (per the established interface) are now  // handled by PHP's magic __set() and __call() methods  // But it still adhere's to the same interface!
    public function testPublicProperties() {

        $row = new User_Row;
        $row->user_name = 'name';
        $row->user_password = 'password';
        $row->user_email = 'email';
        $row->user_url = 'website';
        $this->assertEqual($row->user_name, 'name');
        $this->assertEqual($row->user_password, 'password');
        $this->assertEqual($row->user_email, 'email');
        $this->assertEqual($row->user_url, 'website');
    }

    // This version has additional behaviour - the isDirty property  // is given a TRUE value when the defaults (passed in constructor)  // are changed.
    public function testIsDirty() {

        $row = new User_Row('myname');
        $row->user_name = 'mynewname';
        $this->assertTrue( $row->isDirty() );
    }

    // The __set() method is also designed to only set values whose  // property names are defined in the private $data array. This  // prevents client code adding new arbitrary properties. Attempts  // to add new public properties are ignored.
    public function testNoNewPublicProperties () {
        $row = new User_Row;
        $row->new_property = 1;
        $this->assertNull($row->new_property);
    }
}

As we previously noted. A Transfer Object has a class type – an array has no specific type except the generic “array” (from PHP 5.1). This difference is one further advantage of using this pattern instead of an array. If you take the following client code, any attempt to pass a parameter which is not an object of the type User_Row to the constructor will result in a fatal error. This safety net feature ensures client code adheres to this class’s interface and is not capable of passing other object types or arrays. For example, our User_Row_Printer class below only knows how to work with User_Row objects – giving it any other object might result in unexpected output or a fatal error.

class User_Row_Printer {

    private $user_row = null;
    public function __construct(User_Row $user_row) {

        $this->user_row = $user_row;
    }
    public function print_it() {

        echo $this->user_row->user_name, PHP_EOL;
        echo $this->user_row->user_password, PHP_EOL;
        echo $this->user_row->user_email, PHP_EOL;
        echo $this->user_row->user_url, PHP_EOL;
    }
}

Implementation for PHP4

Implementing a PHP4 Transfer Object is not as effective as in PHP5. The lack of property visibility keywords (private, protected and public) mean that property access cannot be restricted. This rules out effective getters and setters which might replace the PHP5 use of the magic methods __get() and __set(). Getters and setters can be implemented, but without access keywords the client is free to ignore them and access the object properties directly.

Still, the basic structure remains the same and type hinting (if desireable) can be implemented within any method by making an is_a() check against the lowercased class type of the relevant Transfer Object being passed as a parameter to the method.

A simple Transfer Object example for PHP4:

class User_Row {

    var $user_name = '';
    var $user_password = '';
    var $user_email = '';
    var $user_url = '';

    function User_Row($name='', $password='', $email='', $url='') {

        $this->user_name = $name;
        $this->user_password = $password;
        $this->user_email = $email;
        $this->user_url = $url;
    }
}

Unit Testing of the PHP4 version is largely similar to the PHP5 Unit Tests (minus the PHP5 syntax differences).

Conclusion

The Transfer Object is a simple Design Pattern. At first glance it can easily be mistaken for a glorified array but there are a number of important differences. Unlike an array, a Transfer Object has a specific type which allows a class’s method be restricted to only accepting a specific Transfer Object through Type Hinting. While an array can have any number of additional fields appended, a Transfer Object can have a fixed number of properties enforced (see PHP5 complex example code). As a result, Transfer Objects of the same type can always be handled in the exact same way. Another difference is that a Transfer Object can perform its own internal operations when values are set. The PHP5 examples above illustrate how a User_Row object can track whether it’s default values have changed since the object was created thereby allowing client code (perhaps a Data Access class) tell when the database row the Transfer Object represents requires updating.

On a par with an array, a Transfer Object by bundling multiple values in a single entity can help alleviate the long parameter list “code smell” when refactoring and enable methods to return multiple values encapsulated in an object. This is not its primary purpose, but the resemblance to a Parameter Object is close.

The Registry is one of those Patterns where once you understand it, it seems so incredibly useful. Think of it as a basket; using a Registry you can add data (both values and objects) to the basket, and retrieve them as required from other parts of an application. Since all such data is handled by a single Registry object, it makes passing data and objects around an application far more simple than passing all such values as individual parameters to a constructor or setup method. In a similar fashion, a Registry can replace the need to have every object you need global access to acting as a Singleton.

The Registry itself can either be passed around as a parameter or it can be turned into a Singleton to enable global access to it from anywhere in an application. Where it is used to replace numerous Singletons, it can replace the need to know each individual class name which often makes it easier to reuse classes in other applications.

Definition

Definition: The Registry Pattern allows the storing and retrieval of data and objects which need to be accessed globally in a single centralised object.

A PHP 5 Example

At a minimum a Registry allows data to be registered and retrieved, often allowing the setting of a label for the value being registered. One of the most common types of data to use a Registry for are objects for which global access from other objects is required.

This simple PHP 5 example implements a private array to store objects and four methods for registering, unregistering, retrieving and checking the existence of objects.

class My_Registry {

  private $store = array();

  public function __construct() {

  }

  public function register($label, $object) {
      if(!isset($this->store[$label]))
      {
          $this->store[$label] = $object;
      }
  }

  public function unregister($label) {
      if(isset($this->store[$label]))
      {
          unset($this->store[$label]);
      }
  }

  public function get($label) {
      if(isset($this->store[$label]))
      {
          return $this->store[$label];
      }
      return false;
  }

  public function has($label) {
      return isset($this->store[$label]);
  }

}

In addition to the traditional methods, as of PHP 5.1 you can take advantage of the full suite of magic methods to allow.

class My_Registry {

  private $store = array();

  public function __construct() {

  }

  public function __set($label, $object) {
      if(!isset($this->store[$label]))
      {
          $this->store[$label] = $object;
      }
  }

  public function __unset($label) {
      if(isset($this->store[$label]))
      {
          unset($this->store[$label]);
      }
  }

  public function __get($label) {
      if(isset($this->store[$label]))
      {
          return $this->store[$label];
      }
      return false;
  }

  public function __isset($label) {
      if(isset($this->store[$label]))
      {
          return true;
      }
      return false;
  }

}

This could then be used as:

$reg = new My_Registry();
$reg->myObject = new SomeObject();
if (isset($reg->myObject)) {
  // there is a myObject value
} else {
  // there is not a myObject value
}
$obj = $reg->myObject;
unset($reg->myObject);

Implementing the Registry Pattern

Our Registry class “My_Registry” is actually very simple. It supplies methods for registering and unregistering objects, fetching an object known by a “label” string, and in addition lets us check if any object has been registered under a particular label. All objects which are registered are stored in a simple associative array indexed by the labels set at registration. Using labels is optional – one could also retrieve objects by checking their class type via is_a() although this limits the number of objects that can be registered to one of each type.

With the Registry now setup, we can start using it in other objects. I’ll quickly note that unlike the Singleton Pattern examples, the Settings class (below) is no longer a Singleton. By using a Registry we can avoid using multiple Singletons to enable global access to objects. Our example is the same as the one for the Singleton Pattern except we have replaced the use of a Singleton with our new Registry.

class DB_Abstraction_MYSQLI {

  private $settings = null;

  public function __construct($registry) {
      // Settings already exists with imported settings data
      // Fetch pre-existing object using the Registry
      $this->settings = $registry->get('settings');
  }

  public function connect() {
      $conn = mysqli_connect(
          $this->settings->get('db.host'),
          $this->settings->get('db.username'),
          $this->settings->get('db.password'),
          $this->settings->get('db.database')
      );
      return $conn;
  }

  // ...

}

We can use this class as follows, see how we setup the Registry at the start. We register a Settings object which can later be retrieved for use in other objects.

Using the My_Registry class is as simple as:

// setup the registry
$registry = new My_Registry();

// instantiate an object we need global access to (Settings)
$settings = new Settings();
$settings->import('/app/settings.ini');

// register the object for global access
$registry->register('settings', $settings);

// create our abstraction object for use (retrieves Settings from My_Registry)
$db = new DB_Abstraction_MYSQLI($registry);

The Singleton Registry

In the example above, we passed the Registry in as a constructor parameter. An alternative method, which removes the need for constructor parameters is to make the My_Registry object a Singleton. As is common with Design Patterns, combining two or more Patterns often leads to even more useful solutions.

The changes required for our My_Registry class to follow the Singleton Pattern is simple. We just add a new My_Registry::getInstance() method to use a new static class property My_Registry::thisInstance, and make the class constructor private.

class My_Registry {

  private $store = array();

  static private $thisInstance = null;

  private function __construct() {

  }

  static public function getInstance() {
      if(self::$thisInstance == null)
      {
          self::$thisInstance = new My_Registry();
      }
      return self::$thisInstance;
  }

  public function register($label, $object) {
      if(!isset($this->store[$label]))
      {
          $this->store[$label] = $object;
      }
  }

  // ...

}

To use the Registry we now utilise its Singleton method:

// instantiate the registry using Singleton method
$registry = My_Registry::getInstance();

$settings = new Settings();
$settings->import('/app/settings.ini');

$registry->register('settings', $settings);

// no need to pass Registry as a parameter
$db = new DB_Abstraction_MYSQLI();

The change to our Database Abstraction class is equally simple:

class DB_Abstraction_MYSQLI {

  private $settings = null;

  public function __construct() {
      // get Singleton My_Registry object
      $registry = My_Registry::getInstance();
      $this->settings = $registry->get('settings');

 }

 // ...

}

Disadvantages

Patterns are not perfect in all situations and the Registry pattern is no exception. It helps simplify our source code but there are issues to watch out for. For one thing, the use of a Singleton Registry replaces numerous Singletons but still has a global nature. This is warning enough to be careful using the Registry.

Passing it as a constructor may often be preferable since it restricts access to the Registry to those objects which need it. This may not be possible in all cases however.

The Registry poses another issue when it comes to Unit Testing. When unit testing, a developer may setup arbitrary test data in a Registry which the class being tested will utilise once instantiated as an object. However when we implement a Singleton Registry we end up with a situation where creating new Registry objects is not possible – instead every call to My_Registry::getInstance() will return a reference to the exact same object each time – complete with any previously set data.

There are a few solutions to this problem. One could implement a clear() method to delete all Registry values for each new test, or one could implement an array stack (basically a multidimensional array) with non-test data stored to array key 0, and arbitrary test data stored to subsequent numbered keys while providing a mechanism for switching between each stack member. This sounds horribly complicated, however a simple example of our Registry with a stack follows (borrowed liberally from http://www.phppatterns.com).

class My_Registry {

  private $store = array(array()); // array[0]=>array[...]

  static private $thisInstance = null;

  private function __construct() {

  }

  static public function getInstance() {
      if(self::$thisInstance == null)
      {
          self::$thisInstance = new My_Registry();
      }
      return self::$thisInstance;
  }

  public function register($label, $object) {
      if(!isset($this->store[0][$label]))
      {
          $this->store[0][$label] = $object;
      }
  }

  public function unregister($label) {
      if(isset($this->store[0][$label]))
      {
          unset($this->store[0][$label]);
      }
  }

  public function get($label) {
      if(isset($this->store[0][$label]))
      {
          return $this->store[0][$label];
      }
      return false;
  }

  public function has($label) {
      return isset($this->store[0][$label];
  }

  // Test friendly isolation methods for original data

  public function backup() {
      // move $store[0] to $store[1]
      array_unshift($this->store, array());
  }

  public function restore() {
      // remove $store[0], restore $store[1] to it pre-backup() position
      array_shift($this->store);
  }

}

The main difference in the above is that original data is now stored to My_Registry::store[0] which is the first element in a multidimensional array. This lets us shift original data to another numbered key and back – thus emulating a easy backup and restore ability. These method will ensure that Unit Tests accompanying our source code will not be contaminated by data previously added to a Singleton Registry.

Conclusion

We have now covered the Registry Pattern and it close relative, the Singleton Registry, in some detail. We have seen how this Pattern can help remove the need for many objects to utilise the Singleton Pattern while at the same time enabling us additional control over how to inject objects into other objects as dependencies. The Registry is a common solution for allowing objects to access other objects without needing to pass them all as individual parameters to calling object’s constructor method. We have also demonstrated how the Registry can be adapted to facilitate Unit Testing of classes using the Registry without being impacted by data set in prior tests.

Having now covered two methods of handling the inclusion of objects into other objects, the third Pattern remaining to be explored is the ServiceLocator. Another method coming into popular discussion in PHP forums is Dependency Injection which we may cover in the future.