A while ago packt sent me another book to review – this time it was “Code Igniter for Rapid PHP Application Development” by David Upton.
Similar in size to the PEAR Installer Manifesto, this book weighs in at 240 pages, is aimed at developers new to CodeIgniter, and is split into 15 chapters:
- Introduction to CodeIgniter
- Two Minute’s Work: Setting up a CodeIgniter Site
- Navigating your site
- Using CI to Simplify Databases
- Simplifying HTML Pages and Forms
- Simplifying Sessions and Security
- CodeIgniter and Objects
- Using CI to Test Code
- Using CI to Communicate
- How CI Helps to Provide Dynamic Information
- Using CI to Handle Files and Images
- Production Versions, Updates, and Big Decisions
- Instant CRUD – or putting it all together
- The Verdict On CI
- Resources and Extensions
Chapter one is a bare-bones introduction to what CodeIgniter is and why it was initially developed.
Chapter two details how to set up an initial site with CodeIgniter.
Chapter three introduces the reader to the concept of the MVC pattern, what it is about and how CodeIgniter implements it.
Chapter four details the ActiveRecord class for interacting with databases.
Chapter five shows the reader how to specify a View, how to nest them for better reuse and demonstrates CodeIgniter’s Validation class.
Chapter six is about session management and securing applications.
Chapter seven, if the reader requires a refresher, explains Object Oriented Programming and through some examples shows that CodeIgniter does not take advantage of PHP5′s enhancements in that regard. It also looks at the object model in CodeIgniter.
Chapter eight details how to perform unit tests, benchmarking, profiling and how to use mock database objects for test purposes.
Chapter nine is about various machine-to-machine communications: FTP, mail and using xml-rpc for providing webservices.
Chapter ten focuses on internationalization, caching and string manipulation.
Chapter eleven is about file uploads, downloads, compression and image manipulation.
Chapter twelve discusses various topics relevant to migrating your code from your development servers to production.
Chapter thirteen details CRUD operations in CodeIgniter.
Chapter fourteen takes an objective look at what the book has covered as regards CodeIgniter’s abilities and what the author chose to not cover – one admitted omission is a lack of focus on AJAX.
Chapter fifteen, the last one, provides a list of resources and extensions that the dear reader will want to investigate. These include, but are not limited to, graphing and AJAX classes, methods of authentication and CRUD libraries.
The book is written well and the inevitable – yet thankfully small – number of spelling and grammar mistakes in the books don’t detract from the book as much as in the SOA one. I got the impression while reading chapter eleven that the author is not particularly knowledgeable about file permissions on linux/unix and specifies the most permissive options for those platforms which is a bit worrying.
I was amused to find the book “PHP Programming with PEAR” gets a mention in the “Resources and Extensions” chapter, more so because CodeIgniter seems to be a framework that has a chronic case of “Not-Invented-Here” syndrome and attacks the PEAR framework on the main page of it’s website and userguide.
All in all, I found the book to be a straight-forward, educational read and that it works very well alongside the CodeIgniter online documentation.
Well worth the read if you are new to CodeIgniter.
Addendum: Kae asked if reading this book might make me inclined to use CodeIgniter; while I found it very interesting I was also shocked that there is no inclination of embracing and utilising PHP5 enhancements and the chronic NIH present in the framework makes me feel very reluctant to use CodeIgniter. There is a spin-off or fork of CodeIgniter called Kohana that takes advantage of PHP5. It may well be worth investigating.
“I was amused to find the book “PHP Programming with PEAR” gets a mention in the “Resources and Extensions” chapter, more so because CodeIgniter seems to be a framework that has a chronic case of “Not-Invented-Here” syndrome and attacks the PEAR framework on the main page of it’s website and userguide.”
That’s an incorrect assumption. Stating that CI is an alternative for people who don’t want to use PEAR is *not* an attack, and should not be taken at anything more than face value.
CI makes certain design decisions intentionally, and one of those is to make it *easier* to work with other code libraries than similar MVC frameworks like Symfony and CakePHP. I think your claims of “NIH” are pretty off-base.
[...] Ken Guest’s online diary php, linux, pear, mysql etc etc « Book Review: CodeIgniter for Rapid PHP Application Development [...]
Just working on a sample collection of data here:
CodeIgniter’s HTML Table generation class – pear has HTML_Table which has been around since 2002.
CodeIgniter’s Validation class has a pear counterpart – again available since 2002.
CodeIgniter’s Pagination class also has a PEAR counterpart again available since 2002 (link).
The first public version of CodeIgniter was made available, according to wikipedia (couldn’t find this information on the CodeIgniter site), in 2006.
Let me do the maths for you: that’s 4 years lead-time of those pear packages already being available for use.
Now any reasonable person would surely use preexisting packages, especially if they are open source and submit bug fixes or bug reports, rather than expend resources reinventing them.
Go figure.
As regards my impression of PEAR being singled out? Well, that’s my opinion based on the repeated text:
“You are not interested in large-scale monolithic libraries like PEAR.”
There’s no other large-scale monolithic library mentioned, such as the Zend Framework, so I think it’s fair to say that it has been singled out.
“Now any reasonable person would surely use preexisting packages, especially if they are open source and submit bug fixes or bug reports, rather than expend resources reinventing them.”
Eh, maybe, maybe not. It might not have been a good candidate for any number of reasons: licensing issues, for example. I’m speculating, but the current version of CI is based mostly off of work done in ExpressionEngine, which has a very different, much more restrictive license than PEAR.
But a more basic question: does everyone who writes a library similar to an existing PEAR library suffer from NIH syndrome? Do Solar, ZFW, EZComponents, CakePHP, Symfony, PRADO, and Seagull all suffer from NIH? Maybe some do, and maybe some don’t, but I don’t think we can make those conclusions quite so easily.
“As regards my impression of PEAR being singled out? Well, that’s my opinion based on the repeated text…”
Yes, but perhaps it was just used as an example because it’s *by far* the most well-known? I suppose it’s been singled out in a technical sense, but I don’t see any reason to take it as derisive.
In the end, I suppose I just wish you’d *ask* why, rather than assume malicious intent. Derek Allard would be a good guy to start with, and he’s quite good at responding to emails.
PEAR is better known than the Zend Framework (which by the way is far monolithic)?
Awesome.
OK, got that out of the way – truth is I hadn’t considered the licensing issue. Just to clarify, PEAR isn’t a license by the way – developers get a shortlist of licenses to choose from [the PHP, Apache, LGPL, BSD style and MIT licenses]. But yes, I can see why somebody might want similar or same code under a different license.
This is one reason why mysql is dual licensed, I guess – businesses that distribute mysql with their products get to choose a more business/oem friendly license with their wallet, so I can see why some other businesses decide to write their own – either they can’t afford the license fees or they eschew the possibilities of asking the copyright owner to dual-license the software.
I hadn’t thought of asking why PEAR was the only library being referred to, to be honest. Hadn’t thought of laziness to mention another library in an effort to seem balanced!
Hey Ken,
Great review. I did one of the same book on my blog, and was a reviewer of the book before it got published (not for spelling/content, just for glaring omissions or mistakes in the CI code). I also am a dev for CodeIgniter, and just wanted to comment a bit on your post.
Regarding PEAR, we like PEAR. Those guys/gals do generally great work. I’m a fan and supporter of their goals. This is really just a matter of history. While its true that CodeIgniter itself wasn’t released until 2006, the codebase is taken (almost wholesale) from our commercial CMS ExpressionEngine. ExpressionEngine was first released in 2001, and the code in it was around long before then. This obviously pre-dates PEAR. I’m not sure honestly why it was chosen as an example, I suspect due to the instant recognition of the project, but I can say that the homepage mention was a copy/paste job from the manual page you cite. Really, it was only mentioned once – and again, only as an example.
Even if PEAR was available, the licensing concerns (as mentioned) are major hurdles, as our commercial product would not likely be compatible with it. CodeIgniter itself would be, but we are using CI to build EE now, and thus need to be able to distribute the codebase under our own proprietary license.
So that example aside, do you still fee we suffer from NIH?
With respect to PHP 4 vs 5 – I do want to say that CI has separate base files for 4 and 5. We take advantage of PHP5 as much as we reasonably can, and fall back to 4 when we need to for more widespread support. The truth is that I don’t like that I have to support PHP 4, but it is still the dominate PHP version out there, philosophical arguments aside, and we need EE (and therefore CI) to be installable on as many servers as possible. We have every intention of dropping PHP4 support when the market will bear it, but that isn’t today. That said, there is nothing, absolutely nothing, in CI that prevents you from using PHP 5 exclusively, and I do that on my own opensource project, BambooInvoice.
I liken it to supporting Internet Explorer. It may be obsolete, and broken, and I hate it, but there is still a sizable enough group using it that I need to account for them on my site. I notice that you have IE hacks in your own stylesheet
Thanks for the well written review, and I hope to change your mind a bit on some of the points you raise.
[...] all you Codeigniter fans Ken Guest has a review of Code Igniter for Rapid PHP Application Development, it sounds like the book was okay but not good enough to persuade him to use [...]
I was unaware that CodeIgniter inherited a lot of proprietary code that existed before the PEAR project was just a concept – that does indeed change the landscape/factors that lead me to believe that CodeIgniter had a chronic case of NIH.
As regards CodeIgniter with PHP4 and/or PHP5 I have to say that CodeIgniter was noticeable in its absence from the GoPHP5 website – why didn’t CodeIgniter that initiative to influence a better adoption of PHP5, rather than simply put up with the status quo. Quite a number of Irish hosting companies have since then shifted over to supporting PHP 5 and
taking that as a sample I’d take it as a success.
Do you agree with me though that the Zend Framework is also, if not even more so, monolithic that PEAR? All it would take for the CodeIgniter homepage/manual to seem more balanced would be to also refer to ZF – at least then all I would have been able to complain about was the apparent NIH which you graciously pointed out didn’t happen.
@Derek Allard
I like your work on CI but some inaccuracies here:
1. Well, sure ExpressionEngine may have been released in 2001, according to you, but in that iteration it was NOTHING like today’s CodeIgniter. CodeIgniter is a blatant copy of Ruby on Rails (not saying that is a bad thing) which came out much later than 2001. CI is much newer than RoR and borrowed, wholesale, many of its concepts and even directory structure. CI also borrowed heavily from CakePHP which pre-dates CI.
2. Of course CI uses PEAR, at least some of its principles, if not exact code. PEAR does pre-date the modern version of CI. CI, even though you say it was from EE in 2001, is really much newer. And it does use PEAR ideas and code fragments. Period. EE in 2001 was nothing like it is now. Code totally different – not much like RoR at all at that point.
Basically, acting like the 2001 version of EE really has something to do with modern CI (or even modern EE) is not really true.
Again, CI is awesome and you are awesome too, just wanted to clarify the record here. Please make more CI screencasts by the way.