There is no time like the present to start working on a New Year’s Resolution. Unfortunately, I had no intention of doing that today, I had a completely different agenda which was derailed from the word “go”. It started with trying to get Xdebug up and running on my Macbook with Mountain Lion and AMPPS. I must have gone through the build process 20 times before it finally started working because I found someone else who had created a folder full of .so files and I just started running through them until they worked. But I digress…
One of my resolutions is to launch a project this year which will essentially start with a port of something I wrote last year into a standalone application, then I will build on it from there. I have been working on the Roadmap and EER Model for it, and today I wanted to start thinking about how I wanted to develop it. As it happens, the first tweet I saw this morning was from Chris Hartjes, and as I was reading through a bunch of stuff this morning, I really started thinking that maybe the best thing for this project would be to use test driven development.
From there, the next thought became, “Ok, what framework am I going to use?”. I had already made up my mind earlier that I was going to do it on CodeIgniter, and I started trying to get PHPUnit working with it, and it really just was not going well. Then I started thinking about a host of other things I wanted to consider for this app. Namespaces and better autoloading for things like static methods were on that list, neither of which were going to work out very well on a CodeIgniter platform. Don’t get me wrong, I still love using CodeIgniter, and when it comes to getting something up and running in a hurry to meet an urgent need or deadline, it is absolutely my go-to framework. But, when thinking about the sheer complexity of this particular app, I definitely wanted to have every tool available to me that PHP and frameworks in general have to offer.
Enter my New Year’s Resolution. I promised myself that I would pick up another framework this year and I had been introduced to Lithium at Codeworks in a presentation given by Elizabeth Naramore several months ago. So I downloaded it, and went through the obligatory blog tutorial, all of which seemed pretty straightforward. Ok, so chances are I can actually use Lithium and not feel like a complete idiot. So now let’s go through the checklist for my app:
- Autoloading: Native and PSR compliant as far as I can tell. Cannot ask for much more than that.
- Namespaces: Yep, integral to the system and the directory structure revolves around it. Exactly what I was looking for. Check!
- Integration with PHPUnit: NO!…Not needed, as Lithium has an integral testing framework, native to the system and the core code has 90%+ test coverage.
Ok, so this looks promising. Now for the rest of the stuff I use when developing:
- phpCodesniffer: Are there sniffs for Lithium’s coding style recommendations? Couldn’t find any…and again, it doesn’t matter. Lithium has its own plugin for code QA that checks for coding style violations, and the GUI for this is woven into the unit testing GUI.
- APIGen: Lithium has a plugin for this as well, no need to manage it separately.
- phpmd (Mess Detector): Cyclomatic complexity checks are integral to the Lithium unit testing feature.
- Command line tools: Built into Lithium. And I love that I can use the CLI to generate the classes for testing each model.
What impresses me about Lithium? I can see that I will spend less time flipping back and forth between tools because 4 of the ones I currently work with are either built in or are a plugin. Also it is a PHP 5.3+ only framework. This tells me that the devs on this project want to have all tools available to them to produce a framework. And they seem to have done it very well. Also, it seems like the CRUD tools available in Lithium are pretty powerful, and I can see where putting models together for an app is going to be quick, especially if you name your tables so that Lithium will default to them based on class name. I like the use of static methods in Lithium as well. It is well done and promotes speed of development.
Where does Lithium fall short? The User Guide needs a bit of help. It is a little hard to follow, and there are some things that the user guide assumes you know, or you already read somewhere else in the guide. It also seems to allude to other functionality available, but then doesn’t give a lot of detail. This seems to be particularly true for data retrieval. I think that beginning and intermediate programmers may be a little frustrated at first. That said, I still think it is worth the time and the effort to get to know Lithium better. The framework shows a lot of promise, and the architecture of it leaves me with the impression that the devs spent a lot of time thinking through what a developer needs to get the job done quickly.
I can definitely see some tutorial posts and more info on Lithium’s features in the near future!