Introducing the PHP Fever Framework

Posted on 05. Feb, 2010 by Will Fitch in PHP Fever Framework

Overview

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

findByPrimaryKey($id);
    }
}

PHP

<?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

setData($post)->toJson();
    }

    public function __construct()
    {
        parent::__construct(array('db' => \MyApp\Db::getReadInstance()));
    }
}

PHP

<?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.

Close Bookmark and Share This Page

Save to Browser Favorites / Bookmarks

Email This to a Friend

Copy HTML:

If you like this then please subscribe to the RSS Feed.

Tags: PHP, PHP Fever Framework

3 Responses to “Introducing the PHP Fever Framework”

Dallas Gutauckis

06. Feb, 2010

I’m interested… show me more.
Will Fitch

08. Feb, 2010

Hi Dallas,

The public beta will be available in a couple of weeks.
Dallas Gutauckis

08. Feb, 2010

You should invite me to the private beta

Will Fitch's Blog