As a preface, please read this about “magic” code.

It wasn’t that long ago that I gushed about Cake. But after doing some development with it (beta sites for Mockingbird), and after recently working on our current site (which runs on top of Pligg, kinda), I’ve started to kinda think, “hey, what are these guys actually doing for me?”

First, I am still baffled that with all of the auto-sniffing-magic that these frameworks (Rails, et al) do I still have to describe by database schema in two places. I mean, come on, Microsoft solved this problem in .NET. Sure, they do it through code-generation (XML database schema creates the actual underlying database as well as generating all of the C# classes used to interact with it in a completely typed, validated way). But with Cake (and with Rails, AFAIK) I have to go off and do DB admin creating tables and indices and such, and then I have to come and create some parallel classes in the framework. Sure, I don’t have to specify the individual fields, it’ll automatically attempt to map unknown properties for me… unless I want to build-in validation, or relationships, or serialization… you know, trivial little things that only serious webapps would need… ahem. Sure.

Second, I’m just terrified by the amount of decision-making that is made each time “through” the framework when one of my pages is served up. Sure, op-code caching alleviates some of this, but really, should I be executing 10x the necessary amount of code to save me from having to write out a dozen lines of completely self-explanatory, easy-peasy lines of code?

Maybe I’m missing something… maybe these guys are doing a lot of stuff for me I’m not realizing. But I get the itch’n feeling that they’re really just providing a different syntax (with some defaults that make building a bare bones blog in 15 minutes a snap) on bits that are already there, at a lower level.

Routing — mod_rewrite/.htaccess is the only routing tool you need. I almost guarantee you’re not doing anything in your webapp that requires some kind of routing logic that can’t be handled elegantly with mod_rewrite/.htaccess.

Controller — this is the PHP file that your mod_rewrite directs queries to. All you need to do is practice some self-control and keep all of the aesthetic bits out of this PHP file. Just do the work, the logic of the user’s request. When you done all your work, just pass the results off to the view.

View — go download Smarty. Just use it. Flickr uses it and they get more traffic than you ever will. It’s a templating engine designed with the viewpoint that the template should *only* be the view and that the designer and programmer are at least independent tasks if not entirely different individuals.

Model — I was very frustrated with Cake when I tried to combine it with Pligg. Pligg had a particular table/field naming scheme, and Cake had a similar (but different enough) scheme. There was no combination of tweaking that would get one to be compatible with the other. Writing the necessary SQL queries to bridge the gap manually was trivial. And I knew them all along – in fact, I used them when debugging the naming scheme in an attempt to work backwards. Just grab ezSQL, that’s as simplified and automatic as your database interaction should be, because the database is critical (and powerful) if you don’t discount it as just a big property list.

Helpers, Components, Behaviors &mash; these frameworks all have a bunch of additional “utility” features that basically just make life easier as a webapp developer. These could be worth it, if they’re you’re particular flavor. But I bet for each one there’s a strong, healthier open-source version that does more.

Maybe I should put my money where my mouth is? Maybe so. How cleanly could I build a webapp without a framework (and without implicitly building one myself)? In other words, have we heaped one abstraction too many on the pile?