Long, long post warning…
I’m having trouble sleeping tonight. Tomorrow I have to explain to him why it makes no sense to me to try to solve 500 problem tickets on a codebase spiraling out of control (at 2 hours / ticket minimum 1000 hours) then rewrite the damn thing (estimated time 500 hours). Not wanting to go into how and why, complicated.
My thoughts have drifted to my own framework as one possible solution - but it’s not quite up to the task and I want to give it a rewrite to take advantage of features I’ve mastered since the last major overhaul and features new for PHP 5.3. The current codebase needs PHP 5.2 so it’s not a major rewrite in that regard.
Model-View-Control gets a lot of endless debate. I liken it to web developer porn - you know it when you see it but no one quite agrees on what constitutes it. The goal of the paradigm is code separation.
Tonight I brainstormed a bit on what my code does well, the mistakes I’ve made in implementing MVC, and I even pulled up code from back before I heard of MVC to see if those bad old days had any thoughts worth revisiting.
One that called out to me was the elegance of an old framework that organized itself by operations and views. You do an op then return a view. Not too flexiable since it was procedural, but it got the job done with a lot of hard wiring.
It’s very precise and clean. Larger tasks, such as embedding what Joomla and drupal would call modules into a page are not handled as well.
So, I began to think on how I would lay out a framework if I were starting today. An Event perspective on the classic MVC paradigm. Basically every request from the browser is an event, but events can arise elsewhere - an error is an event. If the domain detects the user lacks permissions that is an event. If a view needs a menu inline from somewhere it fires an event.
Model => Data Events: Events that modify or fetch information from the datastore, whatever form it takes.
Control => Event Dispatch: Basically, what happens next. Since events can arise out of events (a successful POST will need to fire a View Event to give the user feedback).
I’m looking at this sketch and typing up this post in hopes of finding holes as there are a lot of smart people here capable of poking holes in things.
Still Reading -> Let’s go in more depth…
Control Code -> Event Dispatch
I think a lot of MVC implementations get lost in determining exactly what control is supposed to do. My own current framework has a lot of view related stuff in it because I proceeded from the idea that templates were the view code and that’s that. They aren’t. They are a component in support of view code yes, but not the view itself.
One thing I intend to keep from my current framework is the idea that ./htdocs is a cache. If PHP can recuse itself from constantly making a page and place a static file in ./htdocs it will. A tiny PHP snippet may be placed at the head of the file to check the time to live for the file and based on cookies whether the page should dynamically load, but the eval of this snippet doesn’t require the framework to load into place so will be faster than pure dynamic pages.
Do As Little As Possible Whenever Plausible
Anyway, due to this structure PHP only is involved when the browser tries to go to a non-existant page. Using Apache mod_rewrite we enter the framework from a single point of entry. This starts the Core class which readies the framework to go to work - setting env, autoloaders, stuff everyone’s framework does in one way or another. At the end the core class starts the Event Dispatcher and hands off program flow to it.
Here’s where the fun starts. The event dispatcher looks at the URL and determines which event is to be fired. It does this by considering the request method ($_POST or $_GET) and mode (HTTPXML or HTTP standard). Having determined the event we go and get it.
The two major event groups are data and view events. So let’s talk about them…
Model Code -> Data Events
As with the controller each MVC has its own ideas on what goes on in the model. To me it’s the access to and from the database and it’s entities.
Above we see control divided into roughly 3 layers - the first layer is pure apache returns of static files without PHP’s involvement, the second layer is the core of the framework which gets the system ready for the other parts and the third is the Event Dispatch.
The Model area also has 3 layers. The Event Layer is the nearest to the control layer and the only one that talks to control (specifically to the EventDispatcher). Events can be the composition of a table summary of data drawn from one or more tables, a form with data bound for one or more tables, and so on. The next layer down is the database abstraction, classes for abstracting tables, rows and fields. Most SQL composition occurs here using SQL that adheres to standard and will run on any database program that likewise adheres to it. Furthest out but closest to the database is the database driver which is where the raw querying happens.
A data event will cause the instantiation of one or more entities, at the least the user entity. Note that the EventDispatcher itself may create the events entity from the database if it has to, but for speed reasons it caches the results of this query to a php file so that the database doesn’t have to be queried on every single page hit. It is possible for a view event to occur without a data event.
View Code -> View Events
View code breaks down into 4 layers.
Template Drivers: This code drives the template evaluation process to compose the output. This layer exists because HTML is not always what we are sending. We may send an image, a PDF, or anything else.
Templates: These are specific to their driver. The HTML templates are simply PHP files in the braceless syntax. Support functions they require live in the HTML drivers.
Putting it together
Ok, still with me?
Thoughts on how this goes. Scenario one - ye old login. We go to the admin home page hitting Core, then Event Dispatch. This fires the homepage data event. The homepage data event discovers no user so fires the authentication fail view event. This event gets the login template, parses it then fires the close session event which does the actual echo out of the code.
The homepage data event requires summaries off the recentWork table, newMessages table, and the session table has an incomplete form that the user didn’t finish yesterday before the user session timed out, so we do an alert to see if the user wants to pick up on that. We fire the view event…
And so on. I think it has promise. It’s a tangent off MVC I haven’t seen before…