PHOOP – An Object Oriented PHP framework – Design Goals

In continuation of the previous blog post on the PHOOP framework’s background, I present here my design goals as I started working on the framework.

I primarily wanted to enjoy the benefits of inline html/php mode of coding for a typical PHP web application, but still make it completely object-oriented. The high-level design goals for the framework were set as follows:

• Simple
  The reason I did not use Zend Framework or CakePHP as my PHP development framework, was that I had an immediate assignment at hand, that needed to be delivered quickly. I had done good-scale PHP work earlier (even with CMSes like Drupal and WordPress), but never got the chance (and time) to explore these established frameworks in detail. So I conceptualized PHOOP to provide a minimal MVC pattern for coding PHP applications to address my immediate assignment quickly.
• Extensible
  Now because the framework itself was petty simple, it had to be flexible and extensible to code real-world enterprise apps using the framework.
• Object-oriented
  I often wonder how a mainstream language that is PHP continue to thrive for so long with its procedural roots, in the contemporary development environment. Procedural approach is my major  cause of repulsion towards PHP and the procedural applications built with PHP.
• Separation of mark-up from code-behind
  This was another much longed-for feature that I really wanted any web framework to have (and was not sure would be provided by established frameworks, another reason I did not opt for them). Let me be fair, I am not aware whether CakePHP etc. support this or not, and I decided it would be more effective to create a famrework from scratch than to explore the existing ones.
• Support for Ajax
  For all web applications I have worked on lately, I have completely eliminated (wherever feasible) post-backs, and instead always exchanged data with the server asynchronously. So, PHP Ajax enabled pages was another goal on the priority list.
• MVC pattern
  The framework needed to be based on MVC pattern for enterprise use. Basically, I visualized 4 layers for the framework:
  • The data layer handling all interactions with any backend data store.
  • Business logic layer that accepts, and processes data and implements all business constraints.
  • The UI layer (inline html/php combination)
  • The UI code-behind layer, that stuffs data in UI layer from Business logic or data layers, and conversely passes data submitted from UI to Business or data layers for processing.
• Targeted for enterprise apps (not for CMS kind of uses)
  I have to accept that between Drupal, WordPress, Joomla (and other available open-source packages), you have everything you need for a regular brochure kind of a site or even a social networking site.
  But the project proposals I receive are often for managing operations of some kind that almost always require custom coding outside a CMS (and many a times are solely for intranet use).
  I needed my framework to allow me to quickly assemble basic architecture required for such custom apps, and then add specific functionality for the app.

It was after considerable time into the development of the framework that I realized my design goals were impacted by ASP.NET. I can vouch that I solely had PHP in my mind together with my previous PHP work while I pondering over the design goals for the framework, and during its initial implementation.

However, into the development, it began appearing that some of the above goals have been passively impacted by my experience with building ASP.NET applications (and my repulsion for the ways I have seen typical PHP applications coded). In the end, I was actually happy that ASP.NET experience impacted my goals for the PHOOP framework, as it helped me realize what I visualized.

The next blog post in this series would give the detailed description of the PHOOP framework itself, together with the code underlying the framework.