The project I’m working on at the moment is a highly complex set of web applications which are intended to bring the majority of a business’ operating processes onto the internet. The prices for products that are sold are based around a significant number of different algorithms and configuration data. Thus it can take time for prices to be worked out.

In order to minimise the initial cost and overall lifecycle cost of the applications, the applications are being developed in PHP and MySQL on a shared server. However, the problem with shared servers is that they prescribe the amount of CPU and elapsed time that can be given over to any one script. So, with a product list of around 1200 items, running one script exceeds those restrictions.

We made a decision when the site was being specified to develop the site around an MVC (Model-View-Controller) architecture. Whilst it’s not unusual for these architectures to be present in web based systems, it’s quite rare to find them in PHP applications. Many PHP MVC architectures slavishly (and fully) mimic architectures available elsewhere (e.g. JSP). These are fairly horrendous to develop and to maintain, since PHP isn’t designed for this, so something more straightforward was required.

Fortunately I discovered Section 4.4 of Sun Microsystem’s book “Designing Enterprise Applications with the J2EE Platform, Second Edition”. This section is quite simply the clearest description of MVC I’ve found – especially since it includes code snippets. Last Christmas I developed some PHP classes for model, view and controller; a supporting class hierarchy for actioning requests and a database table for holding the mapping between action results and views. I don’t claim that it’s flawless, but it does the job well, and hasn’t required any architectural changes since that time.

Going back to the issue of the publishing of prices, I needed something to be able to split the publishing of prices into manageable chunks. Modifying the action that does the publishing involved adding just 30 lines of code. Two minor tweaks elsewhere – a new view for showing progress and a new template that allows the view to invoke the action again (via an HTTP Refresh, thus effecting the splitting of one action into a series of many actions) – and the change is complete.