As written in my earlier blog post, Partholan is aimed at being a lightweight PHP framework for developing a PHP Game/Application. As this project progresses (at an oddly rapid pace), the structure is starting to fall together.

One of the fundamental pits that one can fall into onto any such enterprise is creating a framework so abstract as to be completely unuseable without a very steep learning curve. I think the correct balance is being reached in Partholan which completely omits the IMPLEMENTATION of a model-view-controller, but instead opts for providing common classes which are useful in constructing one. Largely these involve adding potential parent classes which show a standard interface for child classes to follow, sometimes it means adding an entire system prebuilt, in others merely the libraries required for a minimum application.

It’s actually looking rather good so far – though pieces are by necessity a little more abstract than I would have thought required. Thankfully I think I’m avoiding the sort of completely weird theory that I found the other day on Sitepoint. Apparently the powers that be on the forum came up with the idea of creating a “skeletal” FrontController and ApplicationController.

A worthy cause I note – but who would have thought they’d not know what the patterns were? Even those who described an FC and AC got more wrong than right – it took 16 pages of posts, debates, and wild ideas to finally arrive at a Front Controller which actually agrees with the pattern (something I did myself after noting the FC’s highpoint in POEAA in under an hour). Odd folks over at Sitepoint…really odd folks. But being sincere – their discussions did provoke thought so fair play for the constant hammering until the authors achieved what they considered the perfect skeleton script. It did make sense in the end.

Back on topic…

To highlight one “fixed” process in Partholan. The Front Controller implementing the C in MVC. After a little debating and testing I’ve settled on a fairly abstract but still simple to implement (or “roll-your-own”). Here’s how it works – for those yet interested…;-)

The Front Controller is basically an object through which ALL requests to the application must pass. Its purpose for being is to centralise many tasks, e.g. User Validation, Session Management, etc. without duplicating code across all pages. It works by taking a parameter from the request, e.g. “action” in http://myserver/app/index.php?action=index:display and mapping this to a class which actually performs the action (i.e. displays the index page). Now to get this done the FC utilises a special helper to do the mapping – a RequestMapper object. Simply this parses the action parameter, require()’s the relevant action class, instantiates the action class, and returns the object to the FC for execution.

All is not yet finished.

The FC after executing the action object (what we can call the Command) needs to display the page – here doth the funnies begin ;-). To display anything the FC needs to know a few things.

1) What class handles the display (i.e. what View)
2) How the display takes place, e.g. Template, XML, PDF (i.e. the View Strategy)
3) How the Command passes data to the View

Sounds a little odd, yes? Whoa – not too bad, but its certainly getting more abstract and further from the traditional 1 page PHP script most commonly used. But keep up – it’s not too bad, not as bad as Sitepoint authors might make it if they discussed it for 6 months…;-).

The Command we refer to will define a View to be used – whether this View (another object) is actually used is determined by the FrontController (which may well delegate the decision to an Application Controller if needed, e.g. for a multi-page form, or a sequenced process requiring multiple Command calls).

The FC will also determine a View Strategy – for simplicity we’ll assume the strategy is to parse a Smarty Template and fetch the content for display.

Now to tie all this together our Command (and possibly View) objects will generate ViewData – basically the variables needed to parse a template, or be passed via XML, etc. This ViewData object is a glorified array masquerading as an object – but its a nice object that ensures we don’t need to know what array, or where it’s maintained. But it allows us to separate the View from the Command, and the View Strategy from the View AND Command. Separation is important to allow multiple View Strategies and isolate responsibilites between these objects.

To finish the process, we’ll assume the FC generates a View Strategy (Smarty), passes it and the ViewData to the View object. The View will now import() the ViewData into the View Strategy (i.e. this will assign the data as Smarty template variables), and fetch the View Strategy’s final content (i.e. HTML). Finally the View will pass the content to the Response object it was passed (all output passes through this object).

At long last, control returns to the FC. The FC call the Request objects output() method – and our page is displayed.

Complex? Confused? I’m almost inclined to agree off the bat, but from experience this does actually work very well in practice. Need to generate XML, not HTML? Then swap between View Strategies. Need to run multiple commands, with a separate decision determining the View to use? Then our Command/View separation will make this simple. Need to stop Commands duplicating code? That’s one of the benefits of discrete Command objects…

At the end of the day, it works, it’s simple (once explained with a simple example or chart), it’s reusable and maintainable, it can be overridden in a Module system, etc., etc., etc.

It almost too damn useful…;-)

Related posts:

  1. MVC and FrontController: QS 3-0.10