PHP Cookbook

CEHT writes "Like Tony Williams said in his review on PHP and MySQL Web Development: "PHP and MySQL are probably the most pervasive add-ons to Apache web servers across the web". And I agree with him. PHP is a very powerful scripting language, so developers (not just web developers) can do almost anything with it." Read on to see how well CEHT thinks O'Reilly's PHP Cookbook helps you do that almost everything. PHP Cookbook author David Sklar and Adam Trachtenberg pages 608 publisher O'Reilly rating 9 reviewer Edmond Lau ISBN 1565926811 summary Solutions and examples for PHP programmers.

The approach that the authors use in PHP Cookbook is great. Like most computer books, the authors usually include a summary (in sentence forms) to illustrate what the readers will expect in each chapter. Skalar and Trachtenberg take this even further by including some preliminary (code) examples to explain the general ideas behind each chapters. The examples in the book are self-contained. In most cases, I've found examples to exactly fit my needs -- this makes it one of the better reference books.

Each chapter in the book is divided into multiple sections of Problem / Solution / Discussion with a FAQ style. In each case, a simple description of a problem is followed by a PHP script as the solution. But the meat is actually in the discussions: in-depth details are included here, where the authors also include references, extended ideas, and scripts to inform the readers how much more they can do about the issue.

For example, I was going to add a simple script to my website to parse RSS/RDF files from certain news websites (CNN, Slashdot, ...), and use it as my Mozilla homepage. (Who wouldn't?) This script seems to be simple, but I may make a mistake here and there. As reference, I opened up the book to the section "Parsing XML with SAX." Then I realized the authors already had the script to parse RSS/RDF files in the discussion. Bravo!

For myself, the most useful chapters I found are: Web Basics, Forms, Database Access, and XML. There are also good examples in topics such as security, internationalization, and file processing/management. However, this book does not cover the basics of PHP. If you are a good programmer, you should be able to get away with this using the PHP Manual. A good book to learn PHP is Programming PHP, also by O'Reilly.

Although this book covers a wide range of topics, it does not cover topics like generating PDFs. I would also like to see the authors add one (maybe two) case studies in later editions. That would give the reader a more concrete example of how to combine tricks presented by this book. Other than that, at the price of $39.95 (or $61.95 CAD), this book is a great buy!

Topics

1. Strings
2. Numbers
3. Dates and Times
4. Arrays
5. Variables
6. Functions
7. Classes and Objects
8. Web Basics - available online as example chapter
9. Forms
10. Database Access
11. Web Automation
12. XML
13. Regular Expressions
14. Encryption and Security
15. Graphics
16. Internationalization and Localization
17. Internet Services
18. Files
19. Directories
20. Client-Side PHP
21. PEAR

You can purchase the PHP Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Buy a Book v.s Web Resources

[leeroybrown]

I've been doing PHP web development on and off for a couple of years now and I've always found that it's greatest strength has been the availability of very god online resources.

PHP.net and many other excellent resources are only a browser click away and remain up to date for free. PHP is one of those areas where I'll save my money and buy a book I'll get genuine reference use from.

Things PHP is missing

[Anonymous Coward]

1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?

2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!

3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.

4) .NET support?

In short, PHP is a good language for small projects, but just doesn't cut it in an enterprise setting.

Re:PHP Security

[cyt0plas]

The security problems usually aren't the problems of php, it's the developer's problems. PHP is one of the most newbie friendly web development languages out there. For heaven's sake, it even escapes user inputted strings FOR YOU. That stops most sql exploits, shell string exploits at the door. What happens is that some newbie who hasn't taken the time to read the documentation does something dumb like include($_GET['filename']); While this is a exploitable situation, how many CGIs have been exploited because the author failed to strip/escape user input?

PHP has a couple of common mistakes, but I'm far more apt to trust an inexperienced PHP programmer over an inexperienced Perl programmer, as far as secure code goes.

Re:Speaking of FUD

[Publicus]

So what are you saying is better than PHP? Running ASP with Javascript (or ECMAscript to be pedantic)?

If you can tell me that handling forms and working with databases can be done better with something other than PHP please do.

Also, please tell us what is a 'bigger' language, if PHP and *gasp* Perl are so little?

I wonder because I started in ASP with VBScript. I learned Perl and PHP and now I do PHP pretty much full time. If I want a script that is blantent CGI I use Perl. To me PHP and Perl completely blow away (not blow chunks) ASP with VBScript -- they are far better languages for web development. I can't say exactly why I think that, but one of the main things for me is the quality of the community surrounding the language. There's a lot more user support for PHP and Perl which to me is more helpful than the MSDN library will ever be. I also like a lot of punctuation -- but that's just a personal preference.

As far as switching back and forth between languages (JavaScript and PHP, for example), I never thought it was so silly. To me, doing things client-side is distinctly different from doing things server-side. It's no problem to have different languages for those two things. Especially when have to limit what you do on the client side because every browser is different. It seems to me like wasted effort to spend to much time on JavaScript stuff, because lo and behold browser X won't support what I'm trying to do. If I do it server side in PHP, I have an easier time writing portable code.

You certainly have a right to advocate your language of choice, and probably a right to bash others, but could you explain yourself a little better?