Ok, that might be reaching a little.
But still, I recently read this article by Rasmus Lerdorf for the first time and couldn’t help but notice all the similarities to what Tim and I developed for ourselves. It obviously differs in some details (We use Mootools instead of the YUI Library for example) but all the most important design decisions are the same:
- MVC: This one is a no-brainer. Pretty much everything we currently know about building web apps tells us that MVC works well for both initial development and future maintenance.
- Keep things procedural unless something is naturally an object: We have an orm layer and deal with objects but everything else is procedural. A controller is procedural. A view is procedural. Objects for the real-life stuff we represent (and typically store in the db) and procedural for the rest.
- HTML should look like HTML: We use Savant3 for our views as a template engine. This lets views look like HTML. Smarty is retarded.
To those I’d add Keep it Simple. Abstractions are great but only if they reduce complexity, not add to it.
We added two major abstractions:
- Automatic database query handling: We’ll check memcached if you have it installed and spread your reads if you have multiple read slaves while directing your writes to the master. You won’t see any of this. This’ll alleviate db server load.
- Automatic page generation: We’ll automatically generate static pages to be served and serve them when available. This’ll alleviate web server load. If you need to, you can still keep parts of pages dynamic with a simple html comment.
pecl/filter and APC aren’t part of the framework but it’s good to have both installed. The former will help with malicious attacks and the latter will help with performance (by caching PHP objects).
The only thing I’m not sure about is his avoid locks at all costs point. Why would a web framework lock for anything? I don’t think ours ever locks. I can’t help but feel I’m missing something here.
If this framework seemed interesting, keep in touch. In a few weeks after cleaning it up a little and making it general, I’m probably going to be releasing it as open source. To be added before release: REST style url handling (we got fought on that one for framework version 1 but it’s in version 2), a boilerplate generator (which shouldn’t take me long, there isn’t much boilerplate) and maybe clean up some syntax in corner cases. Not that much but worth doing before a general public release. I also want to write a manual (it won’t be very long, the framework isn’t complicated enough to need a book) and some general documentation along with a “hitting the ground running” type document that’ll be the bare minimum you need to know if you just want to slap something up without understanding the inner workings of the framework (that’ll be really short!). Stay tuned.