A More Modular PHP MVC framework

A More Modular PHP MVC framework

By James Myers

  • 14 February 2014
  • PHP, MVC, MVP, Framework

The freedom involved in creating your own framework from scratch allows you to tailor an application that can meet specific requirements whilst not carrying any excess baggage.

It Started With a URL

I was working on project where we had two separate systems which had been developed by two different agencies and had been in place for a while; a website that took bookings and enquiries and an Intranet/CRM system where Sales staff entered information either about bookings or information when they responded to web enquiries .  These were both hosted on different servers with different databases and in different data centres. 

Now the Intranet system needed information from the website in order for the Sales staff to reply to these enquires and to produce quotes etc. such as supplier names, user details, email addresses and other information that was added via the website gateway.  Now a lot of the information that the Intranet needed was to be presented in a similar format than it appeared on the website or the was new functionality that was to be added on the website that involved creating new code to get data that would also be needed to produce reports or interfaces on the Intranet systems. 

So I thought how can I do this in a way that I can present the same data to the website interface whilst also presenting the same data to the Intranet? 

So what we decided was to that all new functionality on the website was to be implemented using an MVC (Model View Controller)/MVP (Model View Presenter)  style system where you create a Model and a Controller/Presenter and the same data can be passed to a view file to render data in the website or accessed via an API and polled via a URL. 

Now for this project we had to work with existing code and refactoring the whole structure was not an option at this time so we also needed the ability to group these Models, Views and Controllers into widgets and be able to plant them on a page, so we developed a system that somewhat resembles below:

Framework API Flowchart

  • On System A widgets are rendered by static method calls to Widget::getWidget for instance in the above image index.php statically calls Widget::getWidget({$$YourController},{$$ids},{HTML}); where:
    • {$$YourController} is the name of your controller class e.g. controller.addressBook.php
    • {$$ids} is either a string or an array of parameters to be passed to the controller
    • {HTML} is the type of view or data that you want return:
      • {HTML} would expect a view file to be made which by default would match the variable {$$YourController} variable e.g. view.{$$YourController}.php but controller.{$$YourController}.php can override this. (Which allows you to use the Views for different Controllers.
      • Other options that can be passed instead of {HTML} are {JSON},{XML},{DATA},{CSV},{EMAIL}

Now from working with this project and integrating this system into existing code and it working well, I was interested in taking it further and to see how I could develop it if starting from a blank canvas.

When looking at developing my own framework I had decided that I wanted several things:

  • Separation of interface and application code
  • The ability to modularise code into reusable widgets.
  • The ability to assign these widgets to different pages.
  • The ability to have dynamic pages that use URL routing to determine what widgets appear on a page.
  • Clean URLS with URL structure
  • The ability to have static pages that can render a widget.
  • Allow different interfaces (Views) to access the same application data
    • For instance if we have PHP web page that displays some application data, we could access the same application data via an AJAX call or XML file without having to rewrite code to generate the same data.
    • API
  • Application data to be cached if required
  • CSS and JavaScript minification/combination
    • Deferred loading
  • Fast loading pages
  • A CMS
    • Ability to easily add new Admin pages for widgets and database tables
      • Define different data and media types to these pages
        • WYSIWYG editor
        • Images
        • Currency
      • Secure login
    • Shopping Cart/ecommerce facility
      • Easily extendible – easy to add new Payment gateways
    • Image uploading/dynamic resizing and ability to define small, medium, large etc.

 

To which I created something that resembles below:

Assign Widgets to Page Framework API FlowchartThe main difference here is that there is a URL routing system in place that allows you to assign widgets to a page and store and retreive them via the pagename in the URL.  This information is stored in a database and is passed by app.model.page.php to app.controller.page.php which will then loop through class.widget.php and render the MVC triad and output it to the page.