The Story of Maveric

FrameWorks, Spiritual Ancestor of Maveric

I've been interested in frameworks and development platforms for several years. In 2006, I started a (now-defunct) project called FrameWorks. FrameWorks 1.0 was primarily a set of reusable classes and tables that would help me stop repeating so much code.

I am a mathematician by training, however, and a programmer only by practice. FrameWorks 1.0 took clues from many more-mature applications I was using at the time: LifeType, MediaWiki, and others. It still supported PHP 4, a strict class inheritance scheme, and other features I quickly began to regret.

While developing a Calendar class for a project at work, we upgraded all our servers to PHP 5, and I took the opportunity to give up the PHP 4 support and rewrite many of the classes from scratch: FrameWorks 2.0. I ditched the inheritance, which was a huge drag on performance, and made a bunch of improvements, especially to the DB object--my only version was an OO-wrapper for the regular MySQL functions, but the goal was to rewrite the internals for several databases.

Very quickly, the Parser class, a regular-expression-powered template engine, began to dominate my time on the project. It eventually developed so much that I considered forking the project into a stand-alone template engine. But reading about the template engines available in PHP, one point kept coming up: PHP is a perfectly good template engine by itself. The project started to slow down.

Applications backed by FrameWorks 2 were fairly unwieldy. A very simple routing system left most of the work to the "modules", which were stored in an ever-increasing number of files. The limitations of the template engine were a hindrance. Memory usage and speed were, to be unfairly kind, lackluster.

FrameWorks Is Put Down

Active development on FrameWorks stopped for several months while I considered the fate of the project. My exposure to other frameworks like Rails and CakePHP, as well as the experience using FrameWorks 2, convinced me that another major revision was needed to take FrameWorks in a more MVC direction.

It would be a lot of work, and I wasn't sure it was worth it.

More MVC

I played with CakePHP and found it overly-complex for what I was doing at the time. Most projects were hovering in maintenance mode, and not worth massive rewrites. Reading up on things like the Java Spring framework still confuses me to this day.

Then a project came along with a fairly loose schedule. I'd been hearing a lot about Rails so decided to use it to prototype the project: I'd get to learn Ruby, Rails, and see what all the fuss was about.

Rails is great, as long as you follow its rules and don't put too much stress on it (Twitter).

Rails + PHP = ???

We were getting our feet wet and loving how little work you had to do with Rails when a much higher priority project kicked us off our leisurely prototype. For speed's sake, we decided to go back to PHP, since we were more comfortable in the language. But I had tasted what a good MVC framework can do for you.

Our new project was an object-oriented programmer's dream: the content types had a clear, real-world hierarchy; classes perfectly aligned with database tables; even the "has-and-belongs-to-many" relationships were easy to see. But how were we going to get that data out to the browser?

So, I gave away the more complex part of the model-building and knocked out the simple part as fast as I could. Then I started building the dispatcher system for an MVC framework, based heavily on Rails and Kohana.

Originally, all I wanted was for this one project to provide both its own user interface, and offer up its data through a RESTful API.

Then another project came up, basically a stripped version of the last one.

Then another.

And another.

Finally, Maveric

Sometime after that second project, I started working on a copy of the dispatcher system and a couple of helper classes. I (somewhat) improved the routing flexibility and built a set of exceptions. I complained a lot about PHP's lack of support for inheritance with static methods. (Hopefully fixed with 5.3's get_called_class().)

Then I finally named it: M + V + C + John McCain's hilarious 2008 campaign = Maveric. I made a bunch of changes before checking in r2, but this is it.

So... why?

Because I like to do things myself, even if they already exist. It's a problem, I know: I'm working on it. But this is fun, anyway.

If you're like me, if you look at a wheel and think "You know, that could work a lot better..." and if you want to work on this little project, let me know.