In this edition…
- About This Newsletter
- On the Blog => An Introduction to jQuery, Continued
- On the Web => Yii Framework
- On the Web => Linux GTD Apps
- What is Larry Thinking? => PHP Frameworks, Revisited, in Relative Detail
About this Newsletter
This newsletter is a bit different in that there are only a couple of things, with a lot of text given to my recent experience with some PHP frameworks. As always, thanks for reading and please do let me know what comments and questions you have!
On the Blog => An Introduction to jQuery, Continued
On the Web => Yii Framework
I’ve been working on a couple of good-sized PHP sites lately and have settled upon the Yii Framework for them (more on my framework experiences later in this newsletter). The Yii Framework had its first stable release around December 2008 and is currently at version 1.0.4. It’s written for PHP 5 and greater and, of course, implements the MVC (Model-View-Controller) paradigm. It’s still a fairly new framework so the documentation isn’t that extensive, but I was pleasantly surprised with how easy it was to use. Without a doubt it’s the closet framework I’ve seen to the very popular (and for good reason) Ruby on Rails. More on the Yii Framework and frameworks in general in a little bit…
On the Web => Linux GTD Apps
In my previous newsletter I extolled the virtues of GTD (Get Things Done) applications, specifically mentioning a couple for Mac OS X. One reader recommended Evolution and BasKet Note Pads for Linux. The former runs on top of GNOME and comes with Ubuntu (and perhaps others); the latter runs on KDE.
As for jQuery, its documentation is very good and there are lots of tutorials online, include the fundamentals and highlights in my blog. Manning Publications has a jQuery in Action book, which I did think to be pretty good.
What is Larry Thinking? => PHP Frameworks, Revisited, in Relative Detail
In my previous newsletter I said “Finally, if I were to start a major Web project today, I’m not 100% sure what I’d use. In fact, I’m working on two for a client and will be using the Zend Framework for both. But I have a couple of personal projects that I’m doing in Rails. And I’m updating some existing projects using just PHP.” This caught the eye of one reader so I thought I’d explain my reasoning in greater detail, then say what really ended up happening.
I’ve written about frameworks in philosophical terms before. Like Object-Oriented Programming (when that’s optional, as in PHP but not Java or Ruby), frameworks can be time consuming to learn but should, once you’ve mastered them, allow you to do more work faster. In fact, the result of using a framework or OOP should be code that’s more reliable and easier to maintain, even if that’s at a slight performance cost. They’re also better when used by a team of people or when concepts are reused. On the downside, both frameworks and OOP require a different way of thinking about things, take extra time to learn, and can be especially challenging when customization is required. I’m generally a procedural and non-framework kind of programmer (again, procedural when that’s an option) because I work largely by myself and I really prefer the directness and immediacy of the results. As much as I know that design and preparation are critical, I really like to type and work and just make things happen right away.
The first framework I ever used was Ruby on Rails, just about four years ago now (when it first came out and caught on). This has, naturally, skewed my sense of what a framework should be. To really appreciate how great Rails is, you just need to watch a screencast to see how quickly you can create a real site using it. Using a terminal or console you enter a command, and the shell of your site—folders, HTML, and code—are generated. Then you make a couple of edits to a configuration file, like specifying the database information. Then you enter commands describing the kinds of information you want the site to manage and the framework creates the database table, the models, the controllers, and the views (the HTML). In fact, it automatically generates everything required for basic CRUD—Create (aka INSERT), Read (SELECT), Update, and Delete—functionality (this auto-generation is called scaffolding). As an example, say you want to store recipes online, so you enter a command describing the information (name, ingredients, time required, etc.), and Rails creates everything necessary to completely manage recipes. In other words, you’re done. That’s it. It all works. Rails really does about 80% of the work for you; from there it’s just a matter of fine tuning. As you can probably tell from my gushing review, I’m a big fan and I really belive that Rails lives up to the hype. You kind of need to know Ruby in the end, though, in order to really tweak the code to do what you want.
As my Ruby skills still aren’t as strong as my PHP skills and I wanted to really see what the PHP frameworks had to offer, I decided to use PHP for these two major client sites I’m doing. I initially went with Zend Framework for a number of solid reasons. First, it’s backed by the biggest PHP player, so it should be continually developed and well documented. Second, it uses only PHP 5 (I don’t see much merit in PHP 4’s OOP). Third, it’s performance numbers aren’t the best of all frameworks but are consistently near the top. Fourth, it has some features I knew I would want, like caching and the Lucerne search. I felt fairly confident about my choice.
I had done some practice exercises using Zend, like going through tutorials and quickstarts, creating simple examples. But when I put Zend (and me) to the test, I eventually gave up on Zend for these projects I’m doing. I just found the Zend Framework to be far too laborious. The one site has over 20 tables so for each model I needed to create one PHP script, then another PHP script for the controller, then a new folder and a new folder within that (I have no idea why views have to be in a subfolder always called “scripts”) and a PHTML file within that for a view. I spent way too much time just creating files and folders and copying and pasting code around. Then there’s the documentation, which is kind of good, except it’s often hard to understand the context in which X code would be used. And there were certain things that really rubbed me the wrong way, like the default of using definition lists for forms and how obtuse it was to change that. There was plenty to like about Zend, of course, but in the end, everything was way too complex and involved and I felt like I was spinning my wheels a lot. The benefit to using a framework isn’t in the first time you do, but I was starting to seriously question my choice.
Within three days I had already duplicated in Yii what had taken me weeks in Zend (to be fair, those weeks also included thinking about the site’s features, models, etc., too). And although there isn’t as much documentation, I found it very easy to follow. The default debugging information was way more helpful than Zend’s, too. And Yii uses ActiveRecord for the data models, just like Rails. Mostly I was just happy not to go around creating files and folders constantly. Yii also uses a command-line tool that performs scaffolding, so most of my time was spent tweaking the auto-generated code instead of creating it from scratch. And these tweaks include doing needed things like turning textareas into TinyMCE rich-text editors, a very simple process thanks to a Yii extension and some code found in the online Yii cookbook.
The first site is still a week or two from being in beta form, but I’m fairly sure now that Yii was the right choice. Largely this is because I’ve spent my time lately actually adding functionality in broad strokes, rather than spinning my wheels in a morass of inter-connected scripts or looking through documentation and trying to figure out in which of the 400 files I was supposed to insert such and such line of code.