[johnboulder]

Hi all

Just in case any of you are interested, I’ve decided to post something here that might help if you’re considering creating a PHP application framework.

First off – you need to consider if you really need to write one – there are a few out there (such as CakePHP – www.cakephp.com, for instance).

Once you’ve looked through the options out there, and decided (like me) that you really couldn’t be bothered to change your own coding style to fit into someone elses – you then need to draw up a list of requirements for the application handler and the modules within that application.

Why modules, I hear you ask – well, consider this – if you don’t want to decentralize your code, there’s no real point to taking an application/data/interface approach.

This is similar to the MVC pattern on www.phppatterns.org, in that the site is split into 3 sections – the application logic (the controller), the interface (or view), and the data (the model).

First off – define what you want the site to do – this is a crucial step, otherwise you’re going to get bogged down when it comes to the details. Lets take a test scenario:

The project we’ll be discussing here is loosely based on my own current project.

Project definition: A site that will allow developers to share their own code and articles, allow comments on each article, and be easily extensible for future module enhancements.

Based on this – we need 3 ‘base’ objects – the application, the data model and the module class (all modules must follow a similar form).

Next, we define what we want our application class to control – in this instance, we want the application to control which modules are used, and the navigation to those modules, in addition to user validation and control. We also want it to be able to pass data to the current module in order for the module to be shown correctly (note: I cannot post any code here, because my project is AJAX powered (see http://xajaxproject.com) – which is out of the scope of this article), we also want the application to be able to pass POST data to the modules – so we define methods for the application as such:

Class Application {
              var $Modules; // class to hold all modules
              var $CurrentModule; // string identifying module
  var $View; // class to control actions on the view (used by modules)
              
    function Application() {
              // whatever code you need to instantiate the object
  }
   
  function Process ($data) {
              // define actions to take when getting a new view
  }
   
  function ProcessForm ($tomodule, $data) {
              // define actions to take when processing a form
  }
   
  }

I would code the user actions under a different class, and link them under Process, as we would any module.

Next you need to define how your modules are called from the application class, and how they return data (ideally they should return data in the View) – ideally, 2 methods should be used – a ‘Run’ method that would allow the module to run based on variables sent to it by the application, and a ‘Post’ method that would control adding data to that modules model..

Once you’ve managed to design this part of the framework, and make sure it’s working – it’s time to set to the interface (or View) – this is relatively simple, as we can have our modules return exactly the kind of data that wont take much jury-rigging to fit.

This is the first in a series of articles on this subject – if it’s helpful – let me know, if you’d like to know more, let me know – and I’ll do another one in a couple of days.

Regards
Sean