Warning: Rant to follow...
When Ruby came onto the scene there was a change of philosophy in shared code. Ruby, in my opinion, really helped to pioneer the idea of a fully developed framework for rapid application development. Rails is the one-stop resource for web development in Ruby, hands down. Before Ruby, the language all others looked up to was Perl and it's idea of shared code is CPAN. If you know CPAN, it's a mess - great console access, but there's no consistency amongst code, documentation is at your leisure and at times there are almost too many options.
Meanwhile, in the background is Java, which just kind of does its own thing in this area, like it always does... suffering from shared code packages and frameworks and everything in between. PHP hasn't been original in this field, for the better perhaps. Originally the big thing was PEAR, which was PHP's solution to CPAN but fixing some of the obvious flaws with CPAN (Note, the originality to this problem for PHP really lies in the PEAR-folks efforts to unify a shared code repository). Lately, though, it's been frameworks! Have you seen, Symfony, Cake, The Zend Framework or Solar?
When I first got into PHP I moved up the ladder to PEAR while looking for a Database Abstraction Layer (but not really though, because in PHP we speak of driver based database solutions as DBA's, even though that's really a whole other beast). The natural choice at the time was DB and eventually I moved up in life to MDB. I also tried a variety of templating solutions available in PEAR, you know one of 50 or so in that package category. Sometimes they were consistent with the bulk of bear, well coded and well documented, and sometimes they weren't. A couple of things were frustrating to me about PEAR though, first for shared-hosting solutions unless you want to hack-up a download of a particular package it's a pain in the butt. You wind up relying on some shared host tech who knows nothing to update the packages at his leisure, and every time you request an update you pull teeth to explain to the aforementioned moron that it's really a good idea. Dependencies in PEAR have also become overkill, you go to use package Q and it depends on X, Y and Z and Y depends on L and M where L depends on E and F. That's fine if you're using the PEAR installer which takes care of these things (ingeniously too at that) for you, but then I go back to the shared environment. Reality is that no everyone has access to the command line on their host, and those that do are not always privy to sufficient access.
While I was struggling to bundle PEAR code in my projects and keep it up to date I finally got frustrated, watching the size of my projects go up exponentially in file size with the addition of every project. So, I went hunting... My database woes were solved by AdoDB and my template woes by Savant (actually designed like a PEAR package, but easy enough to use outside of that context). The immediate benefits of using these libraries were that my file size shrunk considerably. Cool! When we were living in the world of 100mb shared plans this was still important. Moving forward though I still had issues...
I realized that these libraries, as are the case really with any library that covers many developers needs, loaded up a bunch of stuff I just didn't need. I wasn't abstracting out database my queries, just wrapping them for a driver because I was already being careful to write compatible queries with my most often used drivers, mysql, sqlite and postgres. Everything else just got in the way and slowed down execution - with every include there was overhead. At some point I decided to scrap AdoDB and write a very basic wrapper for my DB that utilized the basic core API of AdoDB, Connect(), GetRow(), GetArray(), Execute(), etc. I reduced the file size and reduced the overhead and used exactly what I needed and nothing more. I reuse this component now all the time.
This segues into my issue with the increasing number of frameworks available for PHP. They're huge! They've got a lot of stuff I don't need, but all the baggage gets anyhow. Now, some libraries do better at this than others but the point still stands. Increasingly, PHP frameworks are all MVC-based. Beautiful ideology, it just doesn't always translate over well into being practical. Take a look at the Higher Things website, you'll note that the majority of pages on our site are straight content delivered to the end-user, tasks that can be handled by a basic CMS. However, our landing page, contact page, media page, magazine pages, and a whole bunch of others go beyond the capabilities of a normal CMS. I've never seen an implementation of MVC that allowed for the delivery of CMS content half the time, and then MVC type of development the other half. To say nothing of the fact that sharing controllers in most MVC setups is usually pretty close to impossible if you're using the standard out-of-the-box router/delegation code.
I've strayed away from the framework-craze going across PHP. In larger production environments I need to be concerned about execution speed and all that stuff getting loaded in the framework just gets in the way. All this said, I have my own home-grown framework in place... it is that, yes, it meets the definition - but it's not exhaustive like the open source widely circulated options are, and that's the difference. It's a framework allowing for rapid development wthin the confines of a website's context. It's worked pretty well for me personally. I'd love to see a simple framework out there, but the truth is that it would wind up taking a lot of flack for being restrictive. All along my answer to this has been multiple controllers for a given page, delegated via a page definition. But, that should probably be left for another post...
PHP has gotten a bit stir-crazy lately with the frameworks. Many of these will wind up dying out as developers become frustrated and disenfranchised with them. I think Zend's framework looks promising, and I've always been a fan of Paul Jones work (Savant and now Solar). Will these survive, or get the circulation and developers necessary to keep them alive? Who knows... Meanwhile PEAR is working on their second-generation solution to shared code, Pyrus and I confess it looks promising. Will I switch to using the new Pyrus libraries when it comes out? Likely not, but we'll see... Meanwhile, I press on with the good ol' home-frown stuff.
Post Comment: