Buried in PHP Frameworks

30 Sep

With thanks to “moomin lens” via Flickr

There are 100s of PHP frameworks out there, but I have been so frustrated with so many of them; they are either too complex, not well designed, not well documented, buggy, or all of the above. Also, there is a lot of great technology for PHP that are notfull frameworks. It’d be nice to have a framework that does not try to do everything but, instead, allow easy integration of “best of breed” technologies. And a much more subjectively, only a subset of frameworks out there (though growing) embrace object design as typical of traditional, non-web programming using C++, Java, C#, etc. PHP 5 allows that kind of programming, but not all framework developers have embraced that approached it yet. I’ve spend a non-trivial amount of time with the following (well, I haven’t spend enough time with Kohana, yet):

  • Symfony — very powerful but requiring a very steep learning curve. If all you do is PHP and Symfony, all day long, then this might be for you, but it involves a lot of “moving pieces” and if you don’t use it regularly, you are likely to forget how things work.
  • DooPHP — the style is very much in line with my way of thinking, but the primary download did not work, the documentation was woefully out of date, and it depended on reading and understanding the source or interacting with the few, snide secondary maintainers to understand how to use, at the time, undocumented APIs.
  • PiePHP — tight integration between the front-end code and back-end PHP pieces with many considerations for performance. If your web site happens to match the way that PiePHP is set up, then great, but otherwise the front-end is tightly tangled up with the back end (and it does not appear to be maintained anymore). Due to the lack of documentation and support, this requires a close reading of the source to understand how to use the framework.
  • CodeIgniter — One of the most popular PHP frameworks, today, but I did not like the feel of it; it had the feel old-school web-programming, rather than a modern object oriented approach. This a really bad reason to dismiss a framework, but if I had to do the work, then I’d better be comfortable with it.
  • Kohana — claims to be an object-oriented derivation of CodeIgniter; sounds promising… I wanted to pursue this more, but for reasons that I will get into later, I have not done that yet.

After having gone through several frameworks, I decided that I should expedite my search by enumerating a list of features that I want in a PHP framework. Herewith, my preliminary list of goals and features for a PHP framework:

Desired PHP Framework Features

  • Differentiate between development, test, staging, and production
    • dev vs production data
    • page caching off/on
    • CSS and JS compression off/on
    • Rich error & exception reporting with source code & context display
  • Single point of configuration
  • Logging
  • Mapping of URI to functionality
    • REST handing (and routing)
  • User defined routing/mapping tables
  • Abstracting ROOT path to back-end code
  • Abstracting ROOT path to front-end code
  • AJAX handling
  • XML handling
  • JSON handling
  • Mapping front-end events to back-end handlers.
  • Error & exception handling
  • Page redirection handling
  • First-run initialization
  • No Globals!
  • Separation of framework code from actual public code
  • No dependence of code on its location in directory tree (relatively speaking)
  • Session management
  • Support for UI/JavaScript apps (e.g., event handlers, AJAX integration, dialogs & lightboxes, form & data handling)
  • Decent documentation and support
  • Unit test integration
  • Performant


  • DB abstractions (i.e., ORM; e.g., Doctrine, Redbean)
    • Dynamically updatable tables
  • Templating (e.g., Twig, Smarty)
  • Facebook Connect
  • Facebook Canvas
  • External registrations (OpenID, Google, Facebook, etc.)
  • Emailing form
  • Form handlers
  • jQuery, Blueprint, 960grid, CSS/3, HTML/5 integration
  • Analytics integration (e.g., Google Analytics)

Class oriented

  • Autoload
  • App object
  • Request object
  • Model-View-Controller (probably)
  • Exception based

I would not expect any framework to satisfy all these requirements. And I am sure I will come up with other ideas as I review various options. But I really need to get some work done… So, here is the punch-line: once I finished with list, I realized that I could build a framework that could grow to satisfy my needs. This is the first post in a series as I develop, yet another PHP framework—possibly, one of the stupidest things any PHP programmer could do when there are a lot of others who know more about such things. But the fact is, I am pretty good at designing frameworks and I have been much more productive since I’ve embarked on this effort. I really want your feedback to influence the evolution of this framework. Let me know if you agree/disagree with my decisions. Let me know if you have other ideas on what you’d like to see or that I should investigate or consider.



Tags: , , ,

%d bloggers like this: