Musings on Application Structure

Among other things, I’m currently working on a relatively large CMS/membership site. At the project’s initiation I decided to steer clear of off-the-shelf solutions, partly because I wanted to take myself through the learning curve that the project was sure to involve, partly because none of the CMS or framework options I looked at really appealed to me, and partly because it seemed as though the customisations required to manage this dataset would take nearly as much time as a from-scratch solution.

So far, the development has gone pretty smoothly, but for the past couple of days I’ve been revisiting a few early design decisions with the hope of making the site more flexible. Since google has yet to provide much of use when it comes to this aspect of PHP and Design Patterns, I’m going to try and document my thinking here.

This is by far the largest project I’ve undertaken since developing an awareness of MVC and other design patterns, and I’ve been trying to toe the fine-line of being informed but not defined by them. The largest challenge so far seems to have come as I try to loosen the ties between the layers.

I want to make it easier to add alternative representations of various resources. In some cases, that means atom feeds, in others it may mean FOAF or other RDF representations, and right now it means reusing View classes within the management system. I’ve spent most of the morning reworking my Dispatcher/Controller, and building some sample classes to work with it, and what I have at present is:

  1. Dispatcher uses switch statement to call Controller which builds a model. There are a number of generic model classes, as well as a few specific-use ones
  2. Dispatcher queries request to see if we’re asking for a particular representation, defaulting to XHTML
  3. Dispatcher calls a factory to retrieve a View object, passing the type and a reference to the model
  4. Factory first checks for generic model types and then for specifics, and returns an appropriate View
  5. Dispatcher asks View to produce the output

This is largely achieving the required result, but it’s relying on several large ‘switch’ statements. There’s one in the dispatcher to choose a Controller/Model, there’s one to check the request type, and there’s one to select the appropriate View. I’m trying to work out whether there’s a good way to combine some of that logic, and thereby make it easier to add new Views and new actions.

When it comes to location-awareness, my hunch is that I’d be best off doing some parsing of the referer and the request_uri to work out where we are, and who called us, and then allowing each View to apply its own logic to decide on a template to show and a place to return the user to. Here, I need to work out how best to do that while keeping the system as portable as possible and ensuring code-reuse.

Tags: , ,

Comments are closed.