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
- Q&A => How does one learn JavaScript and/or jQuery?
- 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
My on-going series on jQuery has finally been completed online. There are seven posts in the series, from the basics of jQuery to selecting elements to effects to plug-ins to Ajax, etc. The first one can be found at http://blog.dmcinsights.com/2009/02/05/a-quick-intro-to-jquery/. You can find them all here:http://blog.dmcinsights.com/tag/jquery/. If you haven’t played with it yet or checked out some of the examples you can find online, jQuery is a wonderful JavaScript framework, well worth anyone’s consideration.
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.
Q&A => How does one learn JavaScript and/or jQuery?
This is the million dollar question that I get asked a lot, as many people want to learn more JavaScript and I, among others, strongly recommend that you do. Unfortunately, the general consensus is that there aren’t very good books available for learning JavaScript. And, as far as I can tell, there’s nothing out there for JavaScript like my PHP for the Web: Visual QuickStart Guide (my sincere apologies for the self-referential immodesty, but people do seem to think my first PHP book is a good beginner’s guide). I’ve read several JavaScript books, some I thought were better than others, but I’m not a good test case for what’s a good book, really. For now, I think the best way to get going with JavaScript is by reading tutorials available online. Unfortunately you’re not likely to get a good, cohesive sense of JavaScript this way, but you can hopefully cobble together an understanding of the language in time. I wish I had a better answer here!
That being said, it was my intention to create a free, online JavaScript guide. Something soup-to-nuts for the beginner, like my PHP books. I was slowly working towards that when I got seriously derailed by the possibility of my actually writing a beginner’s guide to JavaScript in book form. I’m still in talks with a publisher about that and will post news when I have it. My fingers are crossed, though, not so much for me to write another book but to provide a needed resource that I don’t think is currently available.
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.
Just about the time I was considering giving up on the Zend Framework, I read about Yii. I decided to play with it a bit before taking the drastic step of scraping everything I had done to that point. Yii is also PHP 5 only and reports excellent, but not necessarily believable, performance scores. There’s just a smattering of documentation available but it has three things going for it that intrigued me: 1) it does scaffolding, although not quite as fully as Rails; 2) jQuery is the built-in JavaScript framework; and, 3), things that are missing, like a good search module, can be added by just using third-party code, like the Zend Framework Lucerne. And to see just how user-friendly and obvious Yii is to use, it has a great built-in tool that reports whether your setup meets the minimum requirements or not. So you can know upfront if something is missing instead of finding out while you’re trying to code.
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.
