Thanks!

1. We can hire contract programmers that already have ZF experience. Although I have tried to keep TF updated with phpdoc api documentation, there is still a learning curve.
2. ZF has many full-time contributors, whereas TF has one contributor who has other full-time obligations in addition to being a husband and father.
3. ZF has many useful modules that allow for rapid development. TF was built to be a minimal MVC framework, and there are many features lacking. Some of these features are not easily extended using other modules.

The decision to use the Thoom framework rather than ZF was partially because my employer needed a quick POC, and at the time, ZF was not even at a 1.0 release. Over the last few years, ZF has expanded and grown to become one of the defacto PHP frameworks. I just have not had the time to keep up with the features that ZF has today.

In January, I was hoping that I would have more time at work and at home to work on my pet project. Unfortunately, life changes and what is important to me has also changed.

So rather than spending time building brand new functionality, instead I have built several Thoom-Zend bridges so that we can utilize the same code for the various projects that I am responsible for. For instance, the Thoom_Db classes can now use Zend_Db_Adapter classes for database connections. Thoom_View templates can use Zend_Action_Helpers and some of the Controller utility methods now mimic Zend Controller Actions like $this->_getParam(), $this->_hasParam(), etc.

The goals I set in January are still valuable; however, I don’t believe that many of them will ever be implemented. It really feels like I will end up mimicking the Zend Framework enough that eventually we will just migrate to ZF from my simpler Thoom codebase.

In a way, I am sad that I may never update Thoom to be what I want it to be. However, I now have time to work on other projects that I am even more excited about, including being more diligent with my tech blogging. In the coming days, I have a few more posts that will go into more details about what I will be doing instead…

Well, l was able to build a version 1 beta of the site and have been using it on a daily basis. What I have come to understand is that I don’t want to create modules for EVERY piece. I am perfectly fine using classes like Zend_Filter or Zend_Validate with my controller or model classes.

After the stresses of moving, having a baby, starting a new job, and the holiday season, I have time to refocus my efforts. As I looked at the pieces I wanted to work on, I decided that I want to focus on having Thoom provide a slim, efficient, interesting MVC base that uses PEAR and Namespaced-style autoloading that allows users to utilize other libraries, such as the beast that is the Zend Framework.

Since the framework was never taken out of a beta, I think that I will break compatibility where it makes sense… and I will deprecate classes that I don’t want or plan to maintain.

I also think I started to reinvent the wheel in some cases… instead of using PHP’s strengths I wrote container classes that provided less functionality…

With the above in mind, the Thoom framework will shrink in overall functionality, but should increase in the areas that matter most.

Thoom_Application: This class replaces Thoom_Loader’s static class. It is one of the only classes that uses a Singleton pattern. It’s strength is the bootstrap class that allows the user the ability to customize the framework data before it launches. The configuration file is passed to the application, so that a programmer can have different files loaded depending on the environment.

Thoom_Config: This base class is extended by the application’s configuration class. In many areas, this class replaces the ubiquitous Thoom_Registry from the version 1 framework. I want to move away from having so many classes tied to the Registry. As I have utilized version 1, I noticed that I rarely used the Registry for anything other than accessing configuration or routed values. I want to utilize dependency injection instead. For instance, classes that used to rely on the Registry for configuration data will instead accept a Thoom_Config object.

Thoom_Controller: This class will more than likely be the key class that breaks compatibility with version 1 sites. I will again utilize dependency injection rather than rely on tying code to the registry. It will be able to access the View, Config, Requests, Session data, from methods like $this->view()->render() or $this->getConfig($variable, $namespace) or $this->request()->getPost($variable) and $this->request()->isPost().

There is also no longer a default action/default controller and all actions are prefixed with the term ‘action’ instead of being suffixed with the term (i.e. public function indexAction(){} in version 1 of the framework becomes public function actionIndex(){} in version 2.)

Thoom_View: I am adding the ability to create view helper classes and their templates. I foresee several view form helper classes that can build a form as well as validate the form elements in a response.

Thoom_Db: I love many aspects of the current Thoom_Db class. One aspect I don’t like is the fact that you either have to pass the configuration to a Thoom_Db based class or you have to rely on the registry. The code looks something like this:

$registry = Thoom_Registry::getInstance();
$dbConfig = $registry->sys->config->database;

This class will no longer be tied to the registry, but will instead expect a Thoom_Config class passed. The configuration will be static, so that it can be passed in the bootstrap. You would be able to do something like this:

class Bootstrap extends Thoom_Bootstrap {
  public function initDb() {
    $app = Thoom_Application::getInstance();
    $config = $app->getConfig(); //Returns a Thoom_Config reference
    Thoom_Db::setConfig($config);
  }
}

In addition, you could create your own db interface (for instance, if you want to use Postgres instead of MySQL). Using Thoom_Db_Adapter_Interface, you could just pass the following in the bootstrap instead (assuming that you have created an adapter class called MyDbAdapter):

public function initDb() {
  $myDbAdapter = new MyDbAdapter();
  Thoom_Db::setAdapter($myDbAdapter);
}

The setAdapter() method prefers to have classes that implement the Thoom_Db_Adapter_Interface, but using reflection, it can verify that the methods the Db requires are available. For instance, you could use Zend_Db to create a MySQLi-based Adapter rather than using PDO.

Thoom_Routes: This class was a late comer in the version 1 beta cycle. Many frameworks make routing so complicated… Instead, I want to provide the ability to simplify the routing process. I will have a regex-based system here, but for the most part, routes are defined in arrays and stored in Routes-inherited class. Thoom_Router will accept Thoom_Routes classes that define module, controller, and action.

These are only a few of the changes that I am planning on making to the framework. I’m pretty excited and plan on posting progress as it happens.

Being a professional web application developer, I wanted to have a place where I can post hints, tricks, tutorials, or just general thoughts on this developing for this big ol’ Internet. I wanted a place that could handle any traffic spikes that may one day come and give me a place to post without worrying about stuff I normally I have to worry about .

Feel free to check back from time to time. I am sure to have something of interest at some point!