In this edition…
- About This Newsletter
- On the Blog => PHP Variables: Passing by Value or Reference
- On the Web => Larry Ullman’s Blog Available Through Kindle
- On the Web => Sign-Up Forms Must Die and the $300 Million Button
- Q&A => How do I dynamically generate pages using a MySQL table’s columns?
- Q&A => How can I generate static HTML pages from dynamic content?
- What is Larry Thinking? => The Yii Framework, Continued
- Book Giveaway => Ruby: Visual QuickStart Guide
- Larry Ullman’s Book News => E-commerce, JavaScript
About this Newsletter
If you’re paying attention to dates (better than I am, that is), you might notice that it’s been more than a month since my previous newsletter and that one was a bit short, too! Well, I’ve been busy. I’ve been working on three good-size PHP-based Web sites, starting work on my e-commerce book, written an article on PHP and Flex, and preparing my house to sell and move. Ugh! But I’ve put together a few more things here and am giving away some books, too. I’m also starting to dig through some old questions I’ve been asked but haven’t yet answered. As always, thanks for reading and for any feedback and questions you may have.
On the Blog => PHP Variables: Passing by Value or Reference
I wrote a little article on my blog on PHP variables and passing them by value or reference. It’s just a quick introduction to the topic, I may expand upon it with more advanced aspects later on. If you don’t know what this means, then you really should give it a quick read. It’ll probably also help your understanding of what happens when functions are called.
On the Web => Larry Ullman’s Blog Available Through Kindle
Through an Amazon service, Larry Ullman’s blog is now available for reading on Amazon’s Kindle. It’s a subscription service, priced at $1.99/month (for what it’s worth Amazon sets the price and keeps most of the money). I don’t know what kind of interest there is in this, but I thought I’d make it an option. This does mean I’ll need to work harder to make the blog content meaningful, though, if people will be paying good money for it! If there’s anything you’d like to see in the blog, or see more or less of, please let me know.
On the Web => Sign-Up Forms Must Die and the $300 Million Button
A reader had previously recommended to me this article titled Sign-Up Forms Must Die. It comes from Luke Wroblewski’s book Web Form Design: Filling in the Blanks (Wroblewski works for Yahoo!). The argument is that sites shouldn’t immediately force users to sign up, just to see what’s possible. Instead, let the user play and see what they can do, then sign up to make their work permanent. I know I’ve gone to sites and left quickly because I didn’t feel like doing another needless registration when I wasn’t convinced I would frequent the site. On a similar note, there’s this article titled The $300 Million Button. It talks about how forcing users to register and login negatively impacts e-commerce sales.
Q&A => How do I dynamically generate pages using a MySQL table’s columns?
In the original question, received some time ago (apologies for the delay), the emailer wanted to know how to have PHP dynamically cope with different MySQL tables, when the specific column names and other details will change from table to table. This is something quite possible and easy to do; in fact, phpMyAdmin relies upon this ability, as does most frameworks. The trick is to fetch the “meta” data: the information that describes the table. For example, the mysql_fetch_field() function returns an object of information about the table used in a query. In other words, you can run any query, like SELECT * FROM sometable, and access the column information by calling mysql_fetch_field() while still accessing the returned data using mysql_fetch_array(). The PHP manual page for mysql_fetch_field() has an example. There’s also mysql_field_name() and mysql_field_type() that just gets subparts of the meta data. If you just want the column names, you can use mysql_query() to run a command like SHOW COLUMNS FROM table LIKE ‘tablename’.
That’s all there really is to it, then you use PHP to handle that information and respond accordingly. A couple of things to note, though: 1) there are Improved MySQL versions of these functions as well (see the manual), and, 2), understand that doing this is convenient and may save programming time, but will hurt the performance of the page (as there are extra queries to be run and functions to be called).
Q&A => How can I generate static HTML pages from dynamic content?
In prevous newsletters I discussed ways to improve site performance, like caching of browser content or caching of PHP code. There’s another kind of caching I mentioned, where the output of a PHP page, which is to say the HTML, is cached as a static file on the server, which is then provided to the browser instead of re-executing the PHP page every time. This is commonly done by frameworks, forums, and so forth. I haven’t ever had the need to develop a system like this myself, but the principle isn’t too hard. There are two processes required: A) the ability to store a copy of a dynamic page as a static file; and, B), a system to determine whether the cached page should be served, or whether the dynamic version should be served and a new cache made of that content.
A search online will turn up some tutorials and code but you need to find those that approach the right kind of caching, like http://www.devshed.com/c/a/PHP/Output-Caching-with-PHP/. Or, if you don’t want to roll your own code, you can use existing tools like PEAR’s Cache_Lite. If I wanted this feature in a site, I’d probably use the PEAR code.
What is Larry Thinking? => The Yii Framework, Continued
In the past two newsletters I’ve been discussing my affection for the relatively-new Yii framework (for PHP 5). In the next couple of days I’ll be wrapping the beta version of the first site I’ve developed using Yii and I’m quite pleased. This is a somewhat complicated site, that uses two different HTML templates, about 20 MySQL tables, three different kinds of users with different permissions, Rich Text Editors (RTE) for administrators, file uploads, and a healthy smattering of JavaScript. I’m still so glad I choose Yii (and dropped Zend Framework). As I mentioned previously, through a command-line tool, Yii generates a lot of code for you, meaning that most time is spent just tweaking existing code, rather than writing or copying/pasting from scratch. It’s also great that Yii includes jQuery, my current favorite JavaScript framework. The best thing is that, for a framework, Yii is relatively simple and obvious. I found that Zend got to be way too complicated for my tastes. And just the other day I discovered something new about Yii, that made me love it even more. Adding one line to the site’s configuration file resulted in a healthy dose of logging information being printed at the bottom of each page: what modules were loaded, how long things took, what objects were used, and what queries were run. It’s just very smart stuff!
An interesting discovery in this framework investigation process was the impact that documentation had. I’m a huge proponent of good documentation (I’m a writer, after all), and that was one of the reasons I initially went with Zend. The Zend Framework has a ton of available documentation, in its manual, in articles, and even in books. But what I found was that I often couldn’t make heads or tails of what was being said. Specifically, I would run across paragraphs that said “add this code to do X” but would have no idea where I would put that code. So I didn’t feel I was getting a good sense of the big picture, and each little tweak often created new problems. Conversely, there’s not that much documentation for Yii. There’s the definitive guide that’s about 150 pages long that discusses the principles with specific code. And there’s a similar guide, maybe 70 pages long, about creating a blog (that goes with corresponding code you can download). There’s also the class reference guide and a forum. The latter is very helpful when search matches are made, and is maintained by the framework’s creator. But one thing I really like it the Yii Cookbook, which has about 20 “recipes” for doing somewhat common but a bit more advanced things. Between the Cookbook and the available extensions, you can quickly and easily do things like incorporate FCKEditor to use for text areas.
Once I finish the beta of this current site, I need to whip out the skeleton for another site, so that the administrators can start importing data. Fortunately, with the Yii framework, I’ll be able to create that skeleton in literally one day. It’s an 80/20 rule: Yii does about 80% of the work for you in no time, the bulk of your time will be spent tweaking that other 20%. Once I get on top of these sites, I’ll try to start writing some specifics about using the framework, for those that are interested.
Book Giveaway => Ruby: Visual QuickStart Guide
You must be subscribed to the newsletter to qualify for book giveaways.
In my next newsletter, I’ll give away the remaining copies I have of my PHP for the Web: Visual QuickStart Guide (Third Edition).
Larry Ullman’s Book News => E-commerce, JavaScript
Well, it’s time for me to start writing again, after a six-month hiatus. In June I’m going to develop all of the code for my E-Commerce with PHP and MySQL book that’s to be published this fall. I’m still cranking out the details, but my intention is to develop and discuss two different examples. Site A will sell virtual content, which is to say anything that’s not a physical product and can therefore be delivered immediately. I think the specific example I’ll use is subscription access to the site, like with a 14-day free trial, followed by paid terms of months or years. PayPal will be used to handle the transaction and the site will require registration and login. This will be a relatively simple and basic e-commerce implementation. Site B will sell physical content and use a shopping cart and a payment gateway to handle credit cards. Registration will not be required (see The $300 Million Button article). For this site, I’ll also create a search, discuss Search Engine Optimization (SEO), and possibly throw in a bit of Ajax. Any feedback is much appreciated. When I’m a bit further along, I will put the code online and would love to have any additional feedback and testing. It’s important to me that this book is really as solid, tested, and useful as possible. (In case you’re wondering, there is an advantage with this book as opposed to some of my others in that I can develop all the code first, then write the book. In a teaching PHP book, I can’t reasonably write all the code first, as things get changed and moved around so much during the writing process.)
My other book news pertains to an alleged JavaScript book, that may or may not ever exist. People have been requesting that I write a JavaScript book for years (and big thanks to you all for the encouragement and interest). I kind of expected it would never happen as most publishers already have a JavaScript book available. So a few months ago I started, slowly, writing an online JavaScript book, in wiki format. Then, in February, while in talks with a publisher about some other books, it came out that they didn’t have a true JavaScript book but did want one. (I’ll leave this publisher unnamed, but it’s not Peachpit Press, whom I often work with.) I spent about two months going back and forth with this publisher but unfortunately the JavaScript book for them is not going to happen. So, after a big delay, I’m going back to my original idea of writing an online JavaScript guide. On the bright side, much of the thought and research that went into developing the idea for a published JavaScript book will translate to the online edition. My intention is to treat the language as a language, like I do in my PHP, Ruby, C, and C++ books. In other words, teach how to use and understand JavaScript, not just a collection of snippets for how to do X and Y. Although there will be plenty of snippets. The intention is really to discuss JavaScript as it is today, which means hand-writing it, frameworks, Ajax, maybe even some Adobe AIR, Google Gears, and server-side JavaScript. And I intend to discuss JavaScript in two ways: as a language itself and how it can be used, and through frameworks. For example, a chapter on handling HTML forms would show how to fetch, validate, and report on the value of the inputs. I’ll show this using raw JavaScript and how the same thing would be done using jQuery or ExtJS. That first bit of knowledge is important for really understanding JavaScript; the latter is important because it’s easier and may be how you end up doing things on a day-to-day basis. The downside of this flirtation with a publisher on a print edition is that my work on this has been much delayed, and it’ll probably be into the fall before I can really get into it again. Although, to your benefit, this material will be free, unlike a printed book, although I’m considering the option of also selling a PDF version of the complete JavaScript guide for a couple of bucks. That’d be much further down the line.
