Two Books On Programming With PHP

A few years ago, knowing just a few html tags and tricks could probably have gotten you a job as a full-fledged Web designer, or at least Web coder. As things get more complicated and Web sites more dynamic, the tools you need to create that all-singing, all-dancing user-interactive content have gotten more complex than carets and single letter tags. Danny Yee wrote these reviews of two of the many available books on PHP programming; to see Danny's hundreds of other reviews, check out the links provided at the bottom.

Web Application Development with PHP 4.0; The PHP Pocket Refere author see each pages see publisher see each rating 8;6 reviewer Danny Yee ISBN see each summary Both of these books are intended to serve as references for PHP programmers, but take different approaches in doing to.

Web Application Development with PHP 4.0 is a book one can actually read: it contains no undigestible slabs of reference material or code (these are relegated to the accompanying CD). Coverage of a wide range of largely independent topics also makes it a great volume for browsing in. And as a system administrator who does only a little bit of programming, in a variety of languages, I appreciated its "broad overview" approach.

The opening chapter of Web Application Development is a very brief look at some general programming issues - code formatting, documentation, APIs - that are all too rarely mentioned in programming language books. The second chapter covers PHP "advanced syntax": lists and arrays, object-oriented programming, and a bit on polymorphism and self-modifying code. (I finally got a handle on PHP's slightly odd handling of lists from this.) And chapter three presents a development example, coding an IRC interface in PHP.

Chapters four through seven cover a large selection of topics: sessions and session-handling, security, usability, validating form data, CVS, COM and Java interfaces, database integration, authentication, templates, XML, and WDDX. Much of this is not at all PHP-specific. Of the thirty-two pages on XML, for example, the first twelve are a general introduction that is not at all language-specific (the remainder describe how to use the Expat and LibXML parsers built into PHP, with examples). And the material on CVS presents some PHP scripts for automating notifications, but is otherwise completely generic.

I found the last two chapters less interesting. Chapter eight contains three case studies of organisations using PHP, but these are more sales pitch than substance (I really don't think it makes sense to be "marketing" PHP three hundred pages into a book on the language). The final chapter of Web Application Development is about modifying the C code at PHP's core. I skipped quickly over this and suspect the vast majority of readers will do the same.

Title; Authors Web Application Development with PHP 4.0; Tobias Ratschiller, Till Gerken Publisher, ISBN New Riders, 0-7357-0997-1 Other 384 pages, includes CD

(Order Web Application Development with PHP 4.0 from Fatbrain.)

The PHP Pocket Reference is right at the other end of the readable/reference continuum. It has two tiny discursive examples (of form handling and database integration) but otherwise is pretty solid: thirty pages introducing PHP syntax are followed by eighty pages of function prototypes with one sentence descriptions. And yes, it will fit into a (large) pocket. I have used the Pocket Reference occasionally, but I suspect only because it has been sitting next to my computer while I write this review -- once it goes onto more distant shelves, using the online documentation will probably be faster.

Title; Authors The PHP Pocket Reference; Rasmus Lerdorf Publisher, ISBN O'Reilly & Associates, 1-56592-769-9 Other 114 pages

(Order The PHP Pocket Reference from Fatbrain.)

Danny Yee's Book Reviews
Home | Subjects | Titles | Authors | Publishers | Latest A book review by Danny Yee <editor@dannyreviews.com>, Copyright © 2000

Comments

Re:Any advantage in PHP over mod_perl

[Rasmus]

Just a couple of comments. There is no additional overhead involved when using Perl-style regular expressions in PHP. In fact, for most things they are actually marginally faster than POSIX-style regular expressions.

I agree, the leak() function is cool:
User: Wha! My script is leaking memory!?
Dev Dude: Don't call the leak() function.
User: Oh yeah, thanks.

You can also include a module in PHP without recompiling. For example, let's say you install Apache, then install PHP (as either a static Apache module or as a DSO) and then you suddenly need to add MySQL support. You can go into your PHP source directory and do: ./configure --with-mysql=shared and it will make you a mysql.so file. This file can be loaded by an individual script using dl('mysql.so'); or it can be loaded globally by putting: extension=mysql.so in your php.ini file.

Advantages to PHP over Perl?

[tzanger]

This isn't meant as a flame or to start a flamewar... This is a valid question I have regarding the two languages and their place.

Perl (mod_perl to be exact) is a huge behemoth. But it allows me to reuse the code I've created over the years to be reused outside of the web realm and without a special "wrapper" program -- just Perl.

I've heard all kinds of people say that PHP is faster... Than perl under mod_perl? I haven't been able to find a decent real benchmark for either. I've coded in PHP, and I've coded in Perl. They both "feel" pretty much the same to me and seem to run just as fast (most of my code is just formatting the output of database requests, since I optimize all the requests themselves instead of pulling in vast reams of information and sorting it in the web server. I don't want to keep two languages just hanging around which seem so similar, as I don't seem to see any kind of advantage to one over the other in the web realm.

Does anyone have any experience or a real-life style of benchmark which would help convince me that PHP is a good thing to keep around even though Perl seems to do most, if not all, of what PHP does and at the same speed?

Again, this is NOT intended as a flame. Seems like a good ontopic post for this particular story though...

Re:Publishers who include CDs ...

[Genom]

Actually, I find that having the full text of the book in some easily searchable format on a CD is a GREAT help.

The New Riders book reviewed above has just such a CD (with the book in searchable PDF format) - I leave the hardcopy at home for reference there, and leave the CD at work -- having a copy at each location without having to lug the book back and forth or buying another copy of a relatively expensive book (let's face it, programming books ain't cheap!) is EXTREMELY handy.

I could care less what else is on the CD.

Re:You will hardly lose points moderating up

[Pac]

The moderation guidelines says clearly that moderators should be more concerned about moderating up than down. Also, I never said the opinions or moderations I metamod as fair were "restating of my own, sheeplike, beliefs". First, aside from a small tendency to flee when I see a wolf coming in my direction, most of my beliefs are hardly sheeplike. Second, I think I haven't made myself clear. I metamod ALL positive moderations as Fair. Never or almost never read the comments they refer to. So I don't have the faintest idea if they restate my beliefs (sheeplike or not). On the other hand, I look very carefully at the negative moderations. Many times I even open the comment thread, to understand both the comment and the moderation. I really believe that a false positive is better than a false negative (and a false positive tend to be corrected far more frequently than a false negative).

Re:The "Programmer to Programmer" WROX books...

[Zico]

Fleet Admiral Ackbar wrote:

Whew, thank G-d I'm not as geeky as those people

Dude, you took the name of a fucking Star Wars character. Who are you trying to kid? :)

Cheers,

Re:The Advances of PHP Documentation

[Azog]

I've been doing a lot of PHP programming over the last two months. Before that I had a lot of experience programming in C++. I think PHP is great. I'm really looking forward to using PHP 4, with the optimizers and precompilers.

I mostly use the online documentation, but I've got the pocket reference by Rasmus Lerdorf. It's pretty helpful once you know the basics, but you probably wouldn't want to learn PHP from it.

One thing that I would like to see covered in the books is PHPLIB. I used PHPLIB for my last project, and man, does that stuff rock! It has very useful code for sessions, authorization, database access, query and table widgets, and more.

You see, one of the problems with doing a nice web app is that HTTP is a stateless protocol - the server gets a series of requests, but doesn't track the flow of the user from one page to another. PHPLIB fixes this with sessions: as long as the user is on the site, they have a unique session ID. Even better, session variables can easily be stored from one page view to the next, and this is nearly automatic. It allows you to forget that HTTP is stateless!

The object oriented design of PHPLIB is pretty good too - I've subclassed the table and query widgets without too much trouble, although PHP has some limitations with inheritance that are a little annoying. (A subclass that overrides a method can't call the implementation of that method in the base class - or at least I don't know any way to do it.)

My only major complaint with PHP is that variables are created implicitly. This is convenient for small scripts, but sucks for complicated applications, since typos in variable names don't cause parsing errors, they just get created as empty variables. On a related note, global variables have to be declared as global inside functions. If you forget, you just get another empty local variable. Similarly, member variables of objects must be referred to as $this-&gt somevar in methods. That's fine, but if you forget - whoops, no error message, just another new, empty variable.

I'm hoping PHP4 will have an option for requiring explicit variable declarations. That would make PHP nearly perfect.

Torrey Hoffman (Azog)

Publishers who include CDs ...

[alkali]

... in books on web development should be forced to eat them. Anyone developing for the web is going to have a net connection by which they can obtain a fresh copy of anything they need (even a 56K modem will usually do in a pinch). Instead, the prices are jacked up by $10/unit and we're stuck with some worthless plastic that makes the back cover unwieldy. Grrr...

Re:Any advantage in PHP over mod_perl

[mcrbids]

Dunno.

Some time back, I figured I'd pick up Perl - it being the "standard" language - and immediately got lost. I tried two different books, as well as an online howto, and got NOWHERE.

PHP, on the other hand, I picked up pretty much immediately with just the phpbuilder site and php.net. At the former site, people were very helpful and I was producing something meaningful (almost) immediately!

I liked it so much I sold my business (computer shop) and now work as a Web developer. (Currently building a full-fledged auction site!) It's fun and rather straightforward.

Couple of caveats:

1) Mixing PHP and HTML sounds nice, (and is for tiny projects) but for any project of any size, you want to implement and use templates from PHPLIB or FastTemplate classes. Otherwise, you get overwhelmed trying to keep track of what it's supposed to look like and what tags and blah blah blah.

2) For mid-to-large size projects, USE OOP!

3) date functions suck in PHP. When saving a date
in a database, don't bother with fancy date functions, as PHP uses 32 bit integer *nix epoch internally to calculate dates - just save the date as an integer and work from there. Limits your dates to 1970-2032, but it's at least consistent since you aren't going from Integer -> db date format -> integer -> final output, you are instead going Integer -> integer -> final output, and PHP can't handle dates outside this effectively anyway.

4) Rather than write for particular database, (Postgres/MySQL) or even to ODBC (which can create driver headaches) write to a generic "db" class you write yourself - and then make that class manage the database. That way, porting to another platform is as easy as updating that single class.

Not sure why I'm telling you all of this - but take it for what it's worth.

-Ben

Web App. Development With PHP 4.0 -- Fantastic

[waldoj]

I actually sent a fan letter to Tobias Ratschiller, I love this book so much. I must confess that I'm only halfway through, but it's really get to see a guide to programming style in PHP, my favorite language. I recommend it highly to anybody that's looking to do PHP professionally.

What I *would* have liked to see in this is more background information on OOP. I've never worked with OOP, so I feel at a bit of a disadvantage. But I'll brush up elsewhere, I guess, but I wish that this would have been included.

Still, this is the #1 PHP book out there, and I can't recommend it more highly. Get it.

-Waldo

-------------------

With PHP, it's pretty much RTFM

[revbob]

I've done quite a bit of PHP3 and MySQL, and apart from a few runs to places listed on the PHP links page and PHP FAQts, I've pretty much gotten everything done with the excellent HTML manual.

About the only thing the manual lacks is an index of functions, but a little bit of experience is generally enough to help you figure out the category under which they've hidden the function you're looking for. I see now that the PDF version of the manual is indexed, so newbies to the manual may want to start there.

OTOH, I'm a long-time C programmer, and when I wondered about syntax, pretending that PHP is C with dollar signs in front of the variable names has worked out more often than not.

Since this page is (presently) screwey and I can't figure out how to reply to an individual posting, in answer to "why PHP instead of Perl?", why not? Oh, all right. Here's a couple of reasons:

• PHP runs in the context of Apache (except the Windows version) which makes it outrageously fast on the UltraSPARC II I'm using most of the time, but then so does perl if you use mod_perl. You'll notice I said nothing about "X is faster than Y". I've found PHP/MySQL to be "very fast" in my applications, and let's leave it at that.
• PHP has got excellent integration with databases (especially MySQL), but I imagine something similar is available for perl.
• PHP is smaller than perl, which means that a PHP mod Apache won't have anything like the footprint of a mod_perl Apache (good to know when you're paying Sun's memory prices)
• There's nothing remotely similar to CPAN, and the Free PHP apps I've seen out there aren't that useful, which means that if you're writing PHP, you're probably doing it mostly from scratch rather than extending others' apps. I actually find this useful. I figure if you're doing server-side scripting, speed is the number-one virtue, and reuse -- at least the kind of reuse I've done -- usually incurs a speed penalty.

So if I were buying a PHP book, the first thing I'd look for are applications that are like the application I'm building to see if I could steal some ideas and code snippets. And I'd look for stuff about the big picture that the originators sometimes forget to put into their documents. But I'm not in the market for a PHP book because the manual is so good and because years in the salt mines of C have pretty well taught me how to code a solution to a problem.

Let me hit on one more thing if I may. When you read the source code, you're reading the truth. When you the canonical documents (the language spec or the documentation supplied with the language) you're one step away from the truth. When you read a textbook, you're two steps away from the truth.

I'm generally too lazy to read the source code (not always -- that's how I learned Unix networking, but there were some special circumstances there or I'd just have read a book like a sensible person), but I've been bushwhacked by enough documentation bugs to do as much learning as I can from the canonical documents.

YMMV, of course.

Re:Any advantage in PHP over mod_perl

[Rasmus]

• PHP can be used for other than web scripts. But you are right, it is definitely geared at web stuff.
• PHP's OO option has been improving steadily and I personally don't think it is all that bad. I never could figure out Perl's OO stuff.
• We are working on that with PEAR. See the pear/ directory in the PHP 4 distribution.
• global is fubarred. Yeah well, personal preference here I guess. I take full responsibility for this one. I had just gotten home from a 20-hour debug session with reams and reams of C code printed out on an old dot-matrix printer. The problem turned out to be a variable in a function that was meant to have local scope stepping all over a global variable. I swore I would never have this problem in PHP and implemented the "declare your globals" feature right then and there.
• system("ls /some/dir"); The result is a listing of /some/dir in your web page. Seems pretty sensible to me. What's your beef on this one?
• Bodged? PHP supports two styles of regular expressions. POSIX 1003.2 regular expression through Henry Spencer's regex library and also Perl-style regular expression through the PCRE library. You are saying these libraries are broken? I personally think Perl-style regular expressions are horrible. Try counting all the different ways the '?' character can be used sometime. I have counted 15 different meanings for '?' and I am sure there are more.
• PHP can generate HTML or you can embed it. Your choice.

And yes, you can run PHP scripts from the command line as well. It is as simple as: php script.php You can even stick the command-line PHP parser alongside perl in /usr/local/bin and write standalone PHP scripts that have #!/usr/local/bin/php on the first line. I am really not trying to convince anybody to dump Perl for PHP. If you know and love Perl, I suggest sticking with what you know.

We have a bad habit in the open source community of beating up on each other. Linux and FreeBSD users fight, Emacs and vim users fight, Gnome and KDE users fight. Perl, PHP and Python users fight. When it comes down to it, these different open source systems are much more alike than they are different and we are not helping ourselves by being overly critical of each other. Constructive criticism and code sharing will ensure the technology advances. Infighting and destructive criticism will ensure that we will drag our old and grey beaten bodies to CompUSA to plop down $400 for an update to Windows-2005 and another $250 for that fix to C# that makes it stop eating all available RAM on a simple database query. -Rasmus

The Advances of PHP Documentation

[Pac]

A few years ago, when I started using PHP (somewhere between versions 1.x and 2.x) for professional web programming, the sole sources of documentation were a tiny manual written by Ramus himself (the same Ramus of the second reviewed book - the reviewer fails to note that Ramus Ledorf was PHP primary creator and maintained it almost by himself until the 3.0 effort) and the mailing list.

It was pretty hard to understand some features without delving in the C source (incidentally, PHP is one of the most well behaved coding efforts I have seem to date. The 1.x,2.x and 3.x sources compile without a flaw in almost any flavour of Unix, and I say almost because I haven't tried them all).

Nowadays, besides the wonderful online documentation, you have lots of books (9 available, 12 coming soon, according to Amazon). It is an easy world.

If you are looking for a place to start, the site is certanly this place. If you need a book, try Core PHP Programming. For a deeper look, Professional Php Programming seems to be the way to go.

And, the reviewer opinion notwithstanding, buy Ramus book and let it rest beside K&R, Wirth and Stroustrup books for a while. Not exactly Ramus league, but PHP is more useful for Web programming in the Web than C,C++ and all Wirth languages combined.

annoted manual at php.net rules

[MattW]

Php.net has an excellent docs section, and I learned to code php and set up a fairly major site from scratch just reading their annoted manual. I will say, if you're new to php, try to read through each section even if you don't THINK you'll need it. There's so many goodies built in, you're bound to miss some. Also, the annoted manual is good because the users offer some clever uses of many pieces of code, or good ways to do things like parse form inputs en masse for illegal characters, or whatever.

I've stuck to online resources

[mu_cow]

These books may be useful, but mostly everything I have needed has been online. The PHP manual is pretty comprehensive and easy to navigate. If you do not have it, download it now!

I have found a lot of help on http://www.phpbuilder.com/ this has a lot of source code, configuration help and helpful forums. From just these two sources you could certainly produce something of slashcode complexity if you have some programming experience.

Everythings Online

[tupawk]

There really is no need for a book on PHP. I taught myself totally from scratch using online resources. Here is a short list of the ones I found most useful:

• PHP - This is the site that started it all. Make sure to check out the documentation section.
• Webmonkey PHP Tutorial - This site is great for getting started with PHP and MySQL.
• PHP Builder - My favorite site about PHP. Lots of good examples and a great message board for all your programming needs!
• Zend - This site is a great portal for more PHP resources.

Hope these sites help out.