Over the past couple of days, I’ve been looking at PHP frameworks for a project. I’ve dug into the PHP MVC world any number of times, and have even used a couple of these frameworks before, but I’ve never been really satisfied with any of them. I’d make a table comparing them, or something, but that’s not really how I work.
Generally, the way I evaluate software is that I just pick something and start using it until I run into a problem that I am not willing to accept or work around, then I move on to something else. Sometimes it takes an hour, sometimes a single project, and sometimes it takes years, but the methodology never changes.
Here’s how it went.
Zend
This time around, I started with the Zend Framework. Why? It’s made by the people who work on PHP itself, so I assumed it would be the most idiomatically sound framework for PHP applications. In other words, applications written using Zend would make sense in the context of PHP expertise.
I downloaded it, set it up on my computer, and got started. The setup was easy enough, and the configuration process seemed reasonable. Then I started going through the Quick Start guide, working through the example application. I got to the section on creating a model. When I started really looking at how Zend models work, I decided that the framework requires too much typing, and moved on to other things.
CodeIgniter
CodeIgniter is a much simpler framework created by EllisLabs. I’ve used it on two other projects, and was vaguely dissatisfied with it, but decided to give it another shot, because I really do appreciate its strengths. My main gripe in the past has been that CodeIgniter models are really DAOs and I’ve been spoiled by Hibernate and ActiveRecord. What’s particularly frustrating is that the documentation is written by someone who doesn’t understand the difference between the DAO pattern and real object-relational modeling, so it’s easy to get the wrong impression of the capabilities of the framework.
CodeIgniter is trivial to set up, and I got as far as creating a new application and implementing some test functionality. The first (minor) disappointment was the fact that CodeIgniter has no built in support for layouts. Fortunately I was able to find a simple workaround on the forums that works quite well.
Then I learned about CodeIgniter’s philosophical stance against the query string. I knew I was in trouble when I read the following in the documentation for the Input library:
Destroys the global GET array. Since CodeIgniter does not utilize GET strings, there is no reason to allow it.
Let me just say, CodeIgniter may not use the GET array, but my application certainly will. Let’s say I’m writing a report that takes parameters like sort_field and sort_order and timeframe. The most sensible way to approach the problem is to include name-value pairs in the URL. Using POST is not an option for reasons of bookmarking alone.
Eliminating the use of parameters in the query string completely is just an awful thing for a framework to do. Given that this is blindingly obvious, lots of people have asked about it on the CodeIgniter forum. There are workarounds that require modifying the core CodeIgniter code (no thanks), but the official word is not good:
It can be fairly polarizing in the forums here, and there are plenty of existing topics to read through, so I’m going to decline to say anything other than it’s the way the framework is designed. CI wants you to use URL segments and have clean, query string free URLs. I understand if that’s not an answer that satisfies you, but I do encourage you to read through the many existing topics on the subject—the workarounds are not very severe nor hard to keep up with across updates. If it’s a feature that’s very important to you and you want to use CI to build your application, you would either need to modify CI (which is one of the great things about open source frameworks) or be willing to work around it with an external solution.
I moved on.
At this point I felt a little stuck, as I thought I was down to PHP ports of Rails. I love Ruby on Rails, but Ruby and PHP are very different languages, and the thought of PHP on Rails brings to mind Samuel Johnson’s most famous quotation:
“Sir, a woman’s preaching is like a dog’s walking on his hind legs. It is not done well; but you are surprised to find it done at all.”
CakePHP
I dismissed CakePHP out of hand, based on minimal involvement in an unpleasant project that used it and lots of complaints about it that I’ve heard second hand. I thought about it for a second, but quickly decided against it.
Symfony
My next thought was to try out Symfony. I had just started digging into some really scary looking documentation when I received a recommendation for …
Kohana
Kohana is a fork of CodeIgniter that keeps all the stuff I like and gets rid of some of the dumb stuff (like the GET method problem). It was easy to set up and easy to get started with, so I’m trying to figure out exactly which parts are the good parts and use those. We’ll see how long the relationship lasts.
March 28, 2009 at 9:50 pm
Oh, I’d love to be able to ask you to try out my framework, but… yeah, it’s still just rough incomplete pieces. Sigh.
Still, it’s got nice concepts. As much REST as I can get it to be, resource-oriented, content negotiation, easy pretty urls, object oriented wrapper around PHP HTTP functions. Eventually I want it to use RDF internally for the data classes, too! Well, I think I do :).
It got started as part of a software project for a university class 2 or 3 years ago, and lately I’ve been hacking on my website (which long ago I originally wrote in a procedural manner in true PHP4 style) towards using and improving upon that framework. But it’s still a way to go, and I wonder if I’ll retain motivation long enough to shape it into something other people can use. I always seem to abandon projects halfway :). Would be nice though if at some point I could get other people into it (although, do I trust other people’s code? :)).
But anyway. I need to look into this DAO vs. ORM thing. I have some object-relational kind of mapping which I like so far, but I really should look at how other stuff does it and what they are doing right and doing wrong. Right now I’m just following my own nose really.
March 28, 2009 at 10:41 pm
This sounds a bit like the person who dates dozens of women but can never commit to one; one’s hair is too long, the other doesn’t fill the salt shaker the right way, etc. That’s not to say that all your quibbles are minor (particularly the one with CodeIgniter), but that your standards seem so high, or your tolerance for other people’s strategies so low, that I doubt you’ll ever find a framework that satisfies you.
Every framework I’ve ever used — even my own — have weaknesses and points of stupidity. The question is, does the benefit of using the framework on a project outweigh the frustration of having to acclimate myself to someone else’s strategies?
March 28, 2009 at 10:48 pm
Like I said, there are many frameworks I’ve used for years. I’m pretty happy with Ruby on Rails, and I like Spring MVC in Java. I used Struts for a long time before Spring MVC came out. But I think that there’s never anything to use forever — something better is always in the works.
March 29, 2009 at 3:20 am
For what it’s worth, Kohana’s been my favorite PHP framework for over a year now. And that’s after spending almost 2 years working on delicious.com with Symfony, CakePHP for most of another year.
I even used Zend for a bit on a personal delicious-like project, but made the decision fairly well down the road to stop the presses and port everything over to Kohana.
Most every PHP framework I’ve seen in the last few years have seemed to be either wishing they were in Java or Ruby, with very few (Kohana included) actually taking advantage of the few advantages PHP offers.
Where Kohana really starts to feel nice is when you start to separate functionality into modules using the cascading file search feature, and using hooks with events to loosely couple those modules into your app.
March 29, 2009 at 5:15 am
“Let me just say, CodeIgniter may not use the GET array, but my application certainly will. Let’s say I’m writing a report that takes parameters like sort_field and sort_order and timeframe. The most sensible way to approach the problem is to include name-value pairs in the URL. Using POST is not an option for reasons of bookmarking alone.”
Is your issue that you want to pass parameters via the url or that you actually want to be able to use GET? I have a hard time believing that you are so passionate about GET that you refuse to use a framework that doesn’t support it.
If the issue is merely that you want to pass parameters via the url, CodeIgiter of course supports this as standard.
Any function within a controller that has arguments are automatically mapped to a corresponding url. Maybe you know this already, or maybe your cursory examination of the framework didn’t make it this far.
I ditched GET when I started using CI a couple of years ago and haven’t really missed it – and I’ve built some fairly big / complicated apps with it.
March 29, 2009 at 10:03 am
I know that you can pass parameters in the URL via segments with CodeIgniter, but in my opinion that’s kind of a mess. I guess in part I like to err on the side of comprehensibility. The framework forces you to do something unnatural for what strike me as capricious reasons. In any case, Kohana has (what seem to be) all the advantages of CodeIgniter, so I don’t feel like I’m missing much.
March 29, 2009 at 10:12 am
Great info! Please do another post when you have more info.
March 29, 2009 at 10:28 am
Just a quick note to let you know that Zend Framework 1.8 will come with Zend_Tool, which may mitigate your “too much typing” issue with it. I’d be interested in what else you might dislike if you gave it another shot in after the stable 1.8 release is out.
April 22, 2009 at 1:39 pm
I am confused. I use CI and I have urls that include ?foo=bar I just use the Input class function $this->input->get(‘foo’, true); and I get “bar”. They do require that the url include enough segments before that to identify the controller and method that the request is dispatched to but the whole “destroy the global GET array” thing doesn’t appear to prevent the use of parameters in the url. Am I missing something?
July 29, 2009 at 10:45 am
Sorry I’m ‘late to the party’ but I’ve started using the prado framework and so far I like the results. It has event type model and makes PHP behave like asp.net – which for some people may be a deal breaker. Does anyone have any thoughts/experience w/ prado?