20 July 2006
The Wealth of PHP Frameworks
I’ve tried a lot of PHP frameworks. I’ve tried the big ones like Prado, CakePHP and Symfony. I’ve tried the usual mix of in-house solutions. And I’ve never found one I’ve liked. Some of my excuses seem superficial, but the thing about programming is that if you’re not completely comfortable with something, it will cripple you.
I don’t like Prado because of its naming conventions and the way by which events are attached to objects. And the learning curve isn’t the greatest. It is, however, a very noble effort. But the PHP platform just isn’t ASP.net yet.
I don’t like CakePHP (or RoR for that matter) because of how deeply tied the database is to the program. Furthermore, while the automated stuff is great, I’ve observed it becomes very awkward to build complex data models without doing it manually and losing the advantages Cake affords you. Finally, its learning curve is worse than Prado’s!
I don’t like Symfony because of the directory structure it imposes on you and that fact it relies on external binaries to generate code. Believe me, PHP is flexible enough that neither should be requirements to use Symfony. As far as what it tries to accomplish, I think that it’s the most reasonable. But that’s just not enough.
Most in house solutions are so-so. They’re customized to a given application, which usually manages to lower at least the initial learning curve. There are still rather large common problems with them: As the rotating door moves, more and more people touch the innards and not knowing design decisions, implement functionality in the wrong place, or put different types of code in inappropriate layers. With a strong core team, they’re good, but most companies can’t seem to dedicate the resources required to keep everything in good working condition. The other common problem is templating. Most of the notorious frameworks do at least an adequate job of keeping views and templates under control. Yet most in-house apps either insist on using Smarty and duplicate their internal data model yet again or just do away with a discrete view layer entirely.
But all and all, that means I’ve not found a framework that satisfies me. And being a programmer, I don’t want to sit for too long on a problem that I can solve.
So today, I announce Fortitude. Fortitude is (currently) comprised of three independent packages which accelerate and ease development of all types of web apps.
The first component is the MVC, often simply called Fortitude. It is a robust and easily expanded controller. The controllers you will use and write are often under 10 lines long, and often, only one line will change from app to app. Controllers facilitate code flow within a module of an application. Even an application itself, if that’s your cup of tea. By default, they only specify where to find actions and establish any aliases for action names. The controller is progmatically accessible to allow easy chained actions. Actions are just actions which have been factored as specifically as possible to maximize reuse. Models are simple classes that establish data fields. Like most home-grown frameworks, the view system is on the weak side.
The next component is the data layer, Fortitude Data Adapter. All data calls should be re-factored into a DataAdapter class specific to a model. All SQL will be hidden in this layer. Models need not know anything about other model’s data structure, only which data adapter a given model uses. By Convention, a Car model will be class-named CarModel (and file-named Car.Model.php). The Car data adapter will be class-named CarDataAdapter (and file-named Car.DataAdapter.php). Both the model and data adapter should sit in a library directory of your site to encourage re-use by different actions belonging to different controllers. But by keeping all SQL in here, changing databases becomes trivial to the rest of your app. But best of all, Fortitude provides an ObjectDataAdapter. This is a fairly complex DataAdapter which can be provided with any model and preform CRUD operations on it, including the data-modeling WITHIN the database. Unlike RoR, you don’t even need to create the table yourself. That means any model-specific data adapter can be 20-some lines long, implementing all its functionality with calls to ObjectDataAdapter. Of course, you can write the SQL yourself for maximum run-time efficiency, but ObjectDataAdapter introduces the fastest RAD I’ve ever used.
Finally, the newest component is Fortitude Forms. Forms addresses the weak part of Fortitude’s MVC. By moving form management into a discrete layer, you have added flexibility to preform validation, re-display forms, or what have you. Forms offers .net-style databinding so that form fields can easily be populated with values out of a model. It has a variety of pre-build HTML controls and it’s easy to build more. Forms also approaches allowing event-driven programming, capturing postback clicks and changes on some control types. The advantage Fortitude offers over other form-generating packages is that its implemented similar to ASP.net’s form package. The is a Form object, which establishes fields, default values, binding options, etc. But it defers actual rendering to a FormView page. FormView pages can be completely PHP-free. Not a single <?=…;?> in the whole file. Instead, you insert a <fort:fieldname /> tag which will resolve to the appropriate field (or error out in the case of typos or missing fields). This separation between View logic (the Form file) and View display (the FormView file) makes it much easier and safer to have designers work on output pages.
There are some extra facilities which are used by components and can be used by your project, such as a using keyword which provides platform-independent path resolution and allows you to include relative to the defined root of a site. And whilst these three components have been developed in tandem, any can be used independently. And many of the features Fortitude implements essentially just import functionality from other frameworks and platforms, notably Java’s Spring web framework and .net’s Form design components. ObjectDataAdapter has no equivalent that I’m aware of. But ignoring the development time in establishing this framework, my productivity is up ~5x since adopting it in full.
Once I get clean samples assembled, I’ll make it accessible. But for now, think of this as a motivator for the other PHP Frameworks.
To append to Brian’s article, I’ve been using CakePHP for quite some time. While I’m an avid fan of RoR, the market penetration of RoR is so low, it’s not even worth developing. However, PHP can be found in the marketplace on almost every corner, thus opening avenues to similar RoR frameworks, specifically CakePHP.
Since CakePHP is based heavily on ActiveRecord, the level in which CakePHP implements the database is very high, thus anything outside database development is most surly a waste of time.
If your coding a website without implementing a database on almost every page, find yourself another framework to use.
While I’d love to recommend CakePHP to you, it’s not worth it. However, if your coding bloqesq websites, or anything that runs atop a database, you bet your ass that CakePHP is the way to go — in my opinion of course…