One of my favourite sayings I tell my daughter when she whines "I wish ..." (usually in response to something I've asked her to do around the house) I remind her that "if wishes were fishes, the sea would be full." Sure, not exactly the type of advice she wants to hear but very true nonetheless.
As I prepare for the upcoming framework apocalypse I started wondering not just what it was about all these frameworks that I have tried that I liked, but what was it about them that I did *not* like. So, in the interest of fairness I thought I'd look at the 3 frameworks I've actually been paid to write code using and what features I'd like to see in them.
Wish #1: CakePHP to abandon PHP 4
There, I said it. I think it's time that CakePHP stop supporting PHP 4 and get on with the task of being a PHP 5-only framework. Last I heard this was the plan for Cake 2.0 but I do not know the timeframe for that. I know that a lot of people think that since 1.2 took so long to go final, my kids will be in college before CakePHP 2.0 comes out. However, knowing how driven Nate, Garrett, and the new superstar on the block Mark Story are, I have faith that a PHP 5-only version of Cake is coming in short order. Please tell me that's true, Nate! Please?
Before you start complaining in the comments, please be aware that I know you can write CakePHP applications using PHP 5. But until the core itself is taking advantage of PHP 5 (via things like autoloading and some of the more advanced OOP magic you can do) I think it's going to continue to suffer performance problems. I love Cake and it's my PHP framework of choice, but that doesn't mean that the wizards on the core dev team can't make it better by leveraging what PHP 5 has to offer).
Wish #2: Code Igniter to abandon PHP 4
Code Igniter is an example of what happens when a company, and the company alone, is the sole driver of development for a framework. At least that is my impression. Code Igniter continually scores well in all those ridiculous "hello world" framework competitions, so you know that it is not dragging a lot of overhead around when doing things. Again, Code Igniter does not use anything available in PHP 5 to its advantage. I know that Kohana is a fork of Code Igniter that is PHP 5 only, and one of our existing applications at work uses it, so those who like Code Igniter's style but want something that is PHP 5 only might want to take a look at it.
Wish #3: Zend Framework gets a good ORM / ADM module
I've been thinking about this a lot lately, and I am starting to like Zend Framework for PHP 5-only projects that aren't database-driven. In fact, if I have to start a new PHP project from scratch at work I'm likely to pick Zend Framework due to it's PHP 5-only pedigree and modular approach to building an application. You literally only have to include what you need beyond a few core libraries. Similar to Code Igniter in that respect but just a little heavier. That's not so bad.
But the reason I still like Cake is that the associative data mapping that they use for database work is flexible and easy to use. Zend Framework needs something like this. If there is one, let me know in the comments.
Wish #4: For the love of god, no more XML configuration files in frameworks!
One of the advantages to Cake is that there is very little you have to do in the way of configuration in order to get started. Code Igniter has even less. Zend Framework? I was taking a look at Zend_Tool, which is their attempt at a CLI code generation tool, and noticed that there are XML configuration files all over the place to get it to work? And Symfony has the same thing.
Look, I deal with XML all day at my day job. It's called XMLTeam Solutions for a reason. But we use it for one thing, and one thing only: presentation of data. We use XSL files to reformat the XML output generated by our application. That is where the use of XML remains.
Configuration files for our main product, a Perl application, are text. The authorization system for our clients is text-based. Our PHP applications use (isn't that strange) PHP files to store the configuration information in them. The handful of Python-based utilities I've written use...text files for configuration. Noticing a trend? Use XML as a way to pass data from one system to another, which is really want it was designed for. Maybe someone can explain to me why configuration files being XML is a good idea, because I just don't see it.
Wish #5: Please buy a copy of my book when it comes out at the beginning of March
I'm getting my basement renovated so I actually have a nice office to work in, instead of working in my cold basement (or from the dining room table due to the current deep freeze in Ontario). Buy my t-shirts too!