Why Another Framework?

Yes, yes, I know you have no shortage of PHP frameworks on the market so why add another into the mix? Truth-be-told, this framework has been around in some form or fashion longer than any of the most well known PHP frameworks including Zend Framework. See, part of the problem is not all of us agree what a framework is so to help frame the rest of this discussion properly let's agree on that, shall we?

Framework Defined

Frameworks are designed with the intent of facilitating software development, by allowing designers and programmers to spend more time on meeting software requirements rather than dealing with the more tedious low level details of providing a working system --Wikipedia

Using the above definition Geeklog is truly a software framework. Until now it wasn't bundled and marketed a such which is fine. As the definition suggests we've been using it for so long focusing on our customer's requirements we haven't really had the time nor motivation to bundle and market it.

Do you Need a Framework?

For many PHP'ers, the word "framework" is a four letter word. Some simply hate the complexity many frameworks bring to the table, others don't like having to black-box certain aspects of their application while others have scalability and speed concerns. All are valid concerns, however, I argue that a good framework can be as complex as you want, as scalable as you need simply by choosing which parts of the framework you really need. To help you, I'll simply point you to a presentation I gave at teh 2008 DC PHP Conference called Fed Up of Framework Hype.

From here on I'll assume you've decided you either need a framework and want to know about the Geeklog Framework works or you still aren't sold on the framework and simply want more information on ours.

Components of the Geeklog Framework

Again, I know "framework" is a four letter word in the PHP community but if you think about the key components it's not all that much, really. Keep in mind your decision to use any of the following are entirely up-to-you:

  • MVC Implementation - Many people hate MVC and feel it can be complicated. Does it have to be? No. We'll cover our implementation called MVCnPHP and let you decide.
  • Persistence Layer - Basic crud operations and queries against your database should be as simple as calling a single function. We use Propel as it is the oldest, most mature PHP5-based persistence layer around. Propel itself can be a bit complicated to first time users and we have tried our best to simplify it's use in our framework.
  • Alternative PHP Cache (APC) - APC provides two things that any framework-base solution (arguably any PHP application) should include. Opcode caching and Shared Memory support. One of the downsides to a framework is they tend to have a lot of small files requiring a lot trips to the filesystem and all those little files have to be interpreted on each request. Using a opcode cache will speed up your applications by caching the intermediate opcodes and, if you properly use require and include, will reduce the number of trips to the filesystem. Of equal interest is by using APC you can also store commonly used datasets into RAM. For example Geeklog uses APC to store the configuration settings as well as the MVCnPHP configuration in memory. The result is a framework that runs as fast as possible.
  • Supporting libraries - We consider the MVC and Persistence layers core to our framework. For everything else we've simply borrowed best-in-class libraries
    • HTML Template Engine - Out of the box we support Flexy. Why not Smarty or some other library? Flexy was the first one to condemn automatic output of HTML and Javascript by default. If you are familiar with some of the common web-based security vulnerabilities, a tool like Flexy can help prevent Cross Site Scripting (XSS) because it will escape all output by default. An additional benefit is Flexy HTML Templates are compiled into PHP code making it fast as well as subject to the same benefits of opcode caching as your other PHP scripts.
    • Logging - Out of the box Zend_Log is powerful and we've simply juiced it up so that logging to any Zend_Log stream is as easy as one, simple static method call.
    • SOAP Toolkit - Today's demands by organizational SOA initiatives and the never-ending requirement of system-to-system integration means your framework must make it easy to expose features as well as consume remote services. The SOAP Toolkit provides you with out-of-the-box support for both contract-first and code-first web services by filling in some of the gaps in the native SOAP support in PHP. Convert any WSDL into a full fledged client library with support for code completion or, with your contract-first scenario take a newly created WSDL and generate the service stub in just seconds. To get started with this we offer these slides.