As we countdown to the public beta release, I want to keep you informed of some exciting functionality that’s being added.

Functionality

Along with the JSON controller, a new XML controller has been added. This allows you to return nearly anything from an action and it will automatically convert it to XML, send the proper content-type header and provide the data to the client. Here is an example of how it would work:

<?php
 
class MyController extends \Fever\Controller\Action\AbstractXml
{
    public function getTestData()
    {
        return array
            (
            'name' => 'Will Fitch',
            'attributes' =>
                array(
                'height' => 76,
                'hair' => 'brown',
                'eyes' => 'brown'
                )
            );
    }
}

This will, in turn, produce the following XML document to the client:

<results>
    <name>Will Fitch</name>
    <attributes>
        <height>76</height>
        <hair>brown</hair>
        <eyes>brown</eyes>
    </attributes>
</results>

Now I’m sure there are those out there that are screaming, “But I want to customize the name of the elements!!!”. No problem! There is a method withing the AbstractXml controller called “setXmlElement” which accepts an instance of SimpleXMLElement. This will be used when converting data provided into XML.

This is all thanks to a new component called “XmlConverter” which lives in the \Fever\IO\Xml namespace. It follows the chain-of-command pattern and iterates until it finds the correct data type provided. Here are a list of converters available for iteration:

• ArrayToXml
• BooleanToXml
• NullToXml
• NumberToXml
• ObjectToXml
• StringToXml

All of these are separate entities, so they can be used independently.

I’ll continue to update throughout the upcoming days before the public beta!

The birth of a new MVC framework, like most others, is spawned by frustrations with the functionality of one or more other frameworks: too much emphasis on design theory, not enough in others, speed, flexibility… the list goes on. The Fever Framework is no different. In an attempt to find a happy medium with design theory, speed, flexibility and latest PHP functionality, this framework is targeted at many audiences from small, shared-hosting environments to enterprise-level web applications. That said, let me provide some goals I’ve kept in mind while developing the Fever Framework.

Some Goals

Design theory and flexibility

I have often wrestled among object-oriented design theory, development time and speed, not to mention optimization which is usually the 800 pound gorilla in the room. Developers deal with this all the time; trying to squeeze a few more days in to ensure the code looks as good as it behaves.

The Fever Framework implements many OOP design theories and MVC functions. However, in some cases, it specifically goes out of the way to provide an easier interface for developers. For example, let’s say you’re implementing a series of actions which return JSON encoded objects. In many frameworks, this is taken care of within the model, provided back to the controller and sent to the browser. In the Fever Framework, you have a few options:

Controller-level

<?php
class MyBlog extends \Fever\Controller\Json
{
 
    public function getPost($id)
    {
        $posts = new BlogPosts();
        return $blog->findByPrimaryKey($id);
    }
}

The above example is a controller which extends the Json controller. The “BlogPosts” class is a model which extends the \Fever\Db\ActiveRecord class. The “findByPrimaryKey” is a method provided within AR. Once the object is returned, the Json controller handles the JSON encoding and sending proper HTTP headers to the client.

Model-level

<?php
class BlogPosts extends \Fever\Db\ActiveRecord
{
 
    public function getBlogPost($id)
    {
        $post = parent::findByPrimaryKey($id);
        return $this->setData($post)->toJson();
    }
 
    public function __construct()
    {
        parent::__construct(array('db' => \MyApp\Db::getReadInstance()));
    }
}

This example returns the data already JSON encoded to the caller. It extends the ActiveRecord class, set’s the data via “setData” (provide in DataModel), and chains “toJson” to the request. This returns the JSON encoded string needed.

This is only two of many ways to achieve the above goal. Design theory and flexibility aren’t mutually exclusive, and flexibility is just as important as design.

Latest PHP functionality

As you’ve already noticed, I’ve incorporated namespaces into the framework. This is especially nice when editing inside an IDE and you can dive down into each namespace to find code (remember the frameworks that use hack namespace styles that make the class name 50+ characters long?). The naming convention is easy to read and makes sense!

Speed

The Fever Framework can be used as a set of libraries, but I’ve taken the liberty to assume you’ll be using autoloading. There is a provided class, Fever\Autoloader which takes care of the inclusion of files for classes/namespaces. Since FF is setup to so that each class falls under a directory based on it’s namespace, autoloading is fast and efficient! With that in mind, there is an important feature (some might argue) you should keep in mind.

Each class comes with a comment block that contains all of the file dependencies as require_once statements. If you so choose, you can remove the comment block and everything will be just fine. However, keep in mind that each require_once call makes a full file scan. This is extremely unoptimized!

When you get the code base , you’ll also notice that a printed stack trace will be relatively short. You won’t have 30 classes printed out that are abstracts of abstracts of abstracts of interfaces. Like I said before, design theory isn’t the most important feature!

Models

As a PHP developer, this is likely where you’ll spend most of your time. Like Zend Framework, Fever doesn’t come with a abstract model. It provides a subset of classes for you to decide to use. For example, if you’re working at the table level, you might choose to use Fever\Db\ActiveRecord, which provides most of the functionality of the Active Record pattern. If you are only using stored procedures, Fever\Db\Procedure might be your choice. But databases aren’t the only types of models. What if you’re working with a SOAP client? You could extend the Fever\Soap\Client, which provides functionality related to SOAP.

Modules

Module-based application development is included. If you choose to use this, you simply add a couple of lines of code to your global bootstrap. If not, do nothing!

Each module is allowed to have its own bootstrap. That means you can customize it as a separate application. You can also define how modules are recognized. If each module is a subdomain, you simply provide that match to the router, and it will recognize it. If it’s a subdirectory, do the same!

Views

To provide some options, the framework comes with both a standard PHP view type as well as Smarty. By default, the standard PHP type is used. This is easily changed within the bootstrap of your application, or even module. Each view type comes with a set of helpers as well.

How do I get the code?

The alpha review will start on February 19th. This will include developer code reviews and testing. This circle will be relatively small (10 – 20 developers) and will last one week. The public beta will begin on February 26th, and a download will be available here.

If you are interested in joining the alpha review, please email me at will[at]phpfever[dot]com or use the contact form.

The ICommand Interface

interface ICommand
{
    /**
     * Run a command
     * @param string $command_type
     * @param args $args
     */
    public function onCommandCall($command_type, $args);
}

This simple interface provides a method for executing a call to initiate a bit of functionality. Along with the classes that execute the functionality, you’ll need a class to handle the chain. We’ll provide this class with another interface requiring the use of a method to add chains and execute commands:

interface ICommandBuilder
{
	/**
	 * Run a command
	 *
	 * @param string $command_type
	 * @param mixed $args
	 */
	public function runCommand($command_type, $args);
 
	/**
	 * Add a new command class
	 *
	 * @param mixed $commanding_class
	 */
	public function addCommand($commanding_class);
}

The two methods here are used for executing commands and adding new command classes. Let’s build the chain-of-command class.

class ChainBuilder implements ICommandBuilder
{
 
	private $_commands=array();
 
	public function runCommand($command_type, $args)
	{
		if (count($this->_commands) > 0)
		{
			foreach ($this->_commands as $class)
			{
				if ($class->onCommandCall($command_type, $args))
				{
					return;
				}
			}
		}
	}
 
	public function addCommand($commanding_class)
	{
		$this->_commands[] = $commanding_class;
		return $this;
	}
}

The class above provides a mechanism for chaining your requests. You add the necessary commands to execute, then pass requests to runCommand, which will loop through all of the commands until one successfully completes the action, or it exhausts all commands. Here you could add interface checks and throw the necessary exceptions for commands not found, etc.

Let’s add a couple of command implementations: email and stream.

class EmailCommand implements ICommand
{
	public function onCommandCall($command, $args)
	{
		if ($command == 'email')
		{
			// send an email with $args
			return true;
		}
		return false;
	}
}
 
class StreamCommand implements ICommand
{
	public function onCommandCall($command, $args)
	{
		if ($command == 'writeStream')
		{
			// Write the stream
			return true;
		}
		return false;
	}
}

These commands email a user and write to a stream. Now let’s use them!

$command = new ChainBuilder();
$command->addCommand(new StreamCommand())->addCommand(new EmailCommand());
$command->runCommand('email',array('email'=>'me@you.com'));
$command->runCommand('writeStream',array('content'=>'Hi, stream!'));

Conclusion

At first glance, the chain-of-command pattern may look like overhead. But on a large code base, this code be useful when making a lot of modifications, etc.

The Observer

<?php
interface IObserver
{
	/**
	 * Method called on event change
	 *
	 * @param mixed $sender
	 * @param mixed $args
	 */
	public function onChange($sender, $args);
}
?>

As you can see from above, the observer implements a single method called onChange. This method is executed when the observable class changes. The first parameter is typically the instance of the class changing and the second arguments relative to the change. Now let’s look at the IObservable interface:

The Observable Object

<?php
interface IObserverable
{
	/**
	 * Add an observer
	 *
	 * @param mixed $obj
	 */
	public function addObserver($obj);
}
?>

The observable class provides a method for one or more observers to be notified. The observable class needs to maintain a list of these observers and notify them when necessary. A common usage of this is a logging mechanism that needs to be notified when data is created, updated and deleted.

<?php
 
class UserLogging implements IObserver
{
 
	public function onChange($sender, $args)
	{
		// Log the changes (we echo here)
		echo 'The class is '.get_class($sender).' and the arguments are '.print_r($args,1);
	}
}
 
class User implements IObserverable
{
	private $_observers=array();
 
	private function notifyObservers($args)
	{
		for ($i=0, $count=count($this->_observers);
			 $i < $count; $i++)
		{
			$this->_observers[$i]->onChange($this, $args);
		}
	}
 
	public function deleteUser($id)
	{
		$db->deleteUser($id);
		$this->notifyObservers(array('user_id'=>$id));
	}
 
	public function addObserver($obj)
	{
		// Add logic for interface implementation check here if you want.
		$this->_observers[] = $obj;
	}
}
 
$user = new User();
$user->addObserver(new UserLogging());
$user->deleteUser(55);
?>

Not only does this provide you some pseudo event access, but this is a much cleaner, maintainable implementation of observing a particular object.

Conclusion

I hope you find ways at work to implement this use pattern. We more often than not get caught up with getting code written (it comes with the territory) and lose sight of these power and proven designs to get the job done. I’m certainly just as much to blame as the next developer! Hope this helps!

PHP provides two interfaces that already define what you should include in an iterator pattern: Iterator and Countable. Below are their definitions:

Iterator Interface

<?php
interface Iterator implements Traversable
{
    public mixed current();
    public scalar key();
    public void next();
    public void rewind();
    public bool valid();
}
?>

Countable Interface

<?php
interface Countable
{
    public int count();
}
?>

You can already iterate over class properties using the foreach() loop, so the Iterator and Countable interfaces are domain specific — meaning the iteration logic is specific to the functionality of the class.

As an example, let’s assume we have a domain model that manages users (CRUD). We have an additional class that acts as a structure (you don’t have to do this, but it’s easier to read in a blog) for each individual user. You also have a method that retrieves an arbitrary number of users, assigns each to a User class (acting as a struct), and gives back an array. While this is certainly doable, the iterator pattern defines an easier way to process the data.

Example Before Iterator Pattern

<?php
 
class User
{
	public $email;
	public $address;
	public $city;
	public $state;
	public $zip;
}
 
class User_Management
{
	/**
	 * List of users
	 */
	private $users=array();
 
	public function getUserByID($id)
	{
		// go get a user and assign it an instance of User
	}
 
	public function getAllUsers()
	{
		// go get all users, assign each to User class, and add to the self::users array
	}
 
}
 
?>

The above example is pretty typical for domain models without the use of iterator. Adding the iterator, we provide an interface to bi-directionally traverse, get key information and count records.

With the Iterator Pattern Implemented

<?php
 
class User
{
	public $email;
	public $address;
	public $city;
	public $state;
	public $zip;
}
 
class User_Management implements Iterator, Countable
{
	/**
	 * List of users
	 */
	private $users=array();
 
	/**
	 * Position of the iterator
	 */
	private $position=0;
 
	/**
	 * Retrieve the current record
	 */
	public function current()
	{
		return $this->users[$this->position];
	}
 
	/**
	 * Return the current key index
	 */
	public function key()
	{
		return $this->position;
	}
 
	/**
	 * Increment the iterator index
	 */
	public function next()
	{
		++$this->position;
	}
 
	/**
	 * Reset the position
	 */
	public function rewind()
	{
		$this->position = 0;
	}
 
	public function getUserByID($id)
	{
		// go get a user and assign it an instance of User
	}
 
	/**
	 * Validate whether a record at current
	 * position exists
	 */
	public function valid()
	{
		return (isset($this->users[$this->position]));
	}
 
	/**
	 * Return the total number of users
	 */
	public function count()
	{
		return count($this->users);
	}
 
	public function getAllUsers()
	{
		// go get all users, assign each to User class, and add to the self::users array
	}
 
}
 
?>

The domain model now implements Countable and Iterator. The below example shows a couple of uses for this:

<?php
 
$iterator = new User_Management();
foreach ($iterator as $index => $value)
{
	// The $index will contain the current key
	// while the $value will contain the user
	// at the current position
	echo $value->address;
}
// Rewind the iterator
$iterator->rewind();
 
while ($iterator->valid())
{
	$value = $iterator->current();
	echo $value->address;
	$iterator->next();
}
 
// Rewind the iterator
$iterator->rewind();
 
for ($iterator->key(); $iterator->valid(); $iterator->next())
{
	$value = $iterator->current();
	echo $value->address;
}
 
?>

Conclusion
This is a much cleaner, easier approach to iterating over objects. I hope you find this usable in your domain models!

For example, let’s assume you have a relatively small system that contains a class called Users. This class reads user data from a small file located on disk. Your system booms, and you need to move to a RDBMS (Relational Database Management System). Because of this, your methods in the class, data source and other items change, breaking the code that is utilizing the Users class. This is where the factory pattern comes in.

The factory pattern’s purpose is to contain methods that create objects for you. Instead of directly instantiating the Users class, you request an instance from a factory class (we’ll call it UsersFactory), and call a static method (we’ll call it getInstance).

Example

<?php
class Users
{
	private $_userId;
	public function getUserById()
	{
		// go get a user
	}
 
	public function __construct($id)
	{
		$this->_userId = $id;
	}
}
 
class UsersFactory
{
	public static function getInstance($id)
	{
		return new Users($id);
	}
}
 
$user = UsersFactory::getInstance($id);
?>

The example above demonstrates how a factory method would work. Now, let’s add in that new class that gets the users from the database. Let’s assume you have 25 other scripts that use the existing class. You can create the new Users_From_DB class and create a static method to reference that as well.

<?php
 
class Users
{
	private $_userId;
	public function getUserById()
	{
		// go get a user
	}
 
	public function __construct($id)
	{
		$this->_userId = $id;
	}
}
 
class Users_From_DB
{
	// same class only from db
}
 
class UsersFactory
{
	public static function getInstance($id)
	{
		return new Users($id);
	}
 
	public static function getUsersFromDB($id)
	{
		return new Users_From_DB($id);
	}
}
?>

This allows you to maintain a loose coupling with a class that could create major problems in the event it goes through major changes.

Conclusion

I have seen where some use the factory pattern as a singleton. They look similar but serve two very different purposes. Take the code below:

<?php
 
class Users_Model
{
	public function getUserById($id)
	{
		// do something
	}
}
 
class Model
{
	private static $instances=array();
 
	public static function factory($model_name)
	{
		if (array_key_exists($model_name, self::$instances))
		{
			return self::$instances[$model_name];
		}
		return self::$instances[$model_name] = new $model_name();
	}
}
 
$model = Model::factory('Users_Model');
$model2 = Model::factory('Users_Model');
?>

While the case could be made that it is acting as a factory pattern, it is being used more as a singleton, maintaining a single instance of a class.

The factory pattern does a really good job, and like the singleton, it serves a very specific purpose.

The singleton pattern is defined as a design pattern that is used to restrict instantiation of a class to one object (or limit number of instances). This is a pretty straight forward concept and works well with many other OOP techniques including the factory pattern. The easiest implementation is to create a public static method within that class that instantiates a new instance.

Example

<?php
class DB_Connection
{
	private $_con = null;
 
    public static function getInstance()
    {
        static $instance=null;
        if ($instance === null)
            $instance = new DB_Connection();
        return $instance;
    }
 
    public function query($sql)
    {
    	// DO SOME CODE TO RUN A QUERY HERE
    }
 
    public function __destruct()
    {
    	$this->_con->close();
    }
 
    private function __construct()
    {
    	$this->_con = new DB::connect('connection_string');
    }
 
}
?>

You’re probably wondering why the class constructor is private. This seems odd as it’s impossible to create an object from outside the class, right? That’s the point. If we don’t limit the class instantiation, the singleton pattern is useless. The method getInstance() can create an object as it’s a member of that class.

How does the static method work?

The static method getInstance() declares a static variable called instance ($instance). The first time this method is called, the $instance variable’s value is null. We then check if the value is null — if it is, we create a new instance of DB_Connection — if it is not, we return the current instance.

Static variables work by declaring the static keyword, then continuing on with the normal variable initialization. The variable will maintain it’s assigned value (whether changed or not) throughout the life of the script.

The second time the getInstance() is called, the $instance variable contains the instance of DB_Connection, and we will return that value. Regardless of how many instances are created of this class, only one object is initialized.

Conclusion

As you can see, the singleton pattern certainly has it’s uses, albeit specific. Keeping the OOP design patterns in mind makes for a cleaner, easier to maintain code base for future developers picking up your projects.

This is caused an uproar in the community and I’m personally not a fan of it. At the same time (and after many weeks of debating), I have decided to support this effort. While I’m not a fan of its implementation, I’m still pleased that namespace functionality is being implemented into PHP.

Your thoughts?