PHP Cookbook
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
- Strings
- Numbers
- Dates and Times
- Arrays
- Variables
- Functions
- Classes and Objects
- Web Basics - available online as example chapter
- Forms
- Database Access
- Web Automation
- XML
- Regular Expressions
- Encryption and Security
- Graphics
- Internationalization and Localization
- Internet Services
- Files
- Directories
- Client-Side PHP
- 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.
One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.
Don't get me wrong, I find PHP to be the best and friendliest solution for many things, but some of the Security problems could easily be avoided with some common sense security advice.
Before I begin, let me just clarify something. I'm not arguing that PHP is better than Perl in all cases. There is certainly still a use for Perl. Also, PHP isn't perfect but it does manage to fix many of the shortcomings I've had with Perl. Here are a few of the things I've noticed about PHP. Finally, I'm not the most talented Perl programmer out there. I generally prefer to use the vastly superior Python, but can use Perl if I have to.
- Ease of use. After about a day I had an excellent understanding of
both PHP and SQL. I was able to get a stable, useable and presentable
website up within 24 hours of reading the basics of PHP. Learning Perl
took me weeks and I'm still not even as good with it as I am with PHP.
I would definitely not recommend anyone new to programming begin with
Perl.
-
The OO of PHP is excellent. In my experience, it rivals Smalltalk.
We all know that Perl's OO still needs work (whether or not OO is all
that great is another discussion.) Hopefully Perl will be patched up
so it supports such must-have OO features like introspection,
reflection, self-replication and ontological data-points.
-
Outstanding database support. PHP supports virtually every DB under
the sun (although Berkeley DB is missing, oddly enough.) Perl seems
limited to MySQL and PostgreSQL, and its really a kludge for the
later. I've heard that this will be fixed in upcoming versions of Perl
though.
- Speed. PHP is one of the fastest languages I've ever used. While it
won't be replacing assembly or C, its definitely faster than Perl in
almost every case, particularly in regex which has long been Perl's
strongest point. I'm sure there are cases where Perl is equal to PHP,
but I can't think of any at the moment.
- Portability. I can take PHP code off my Linux box and plop it onto
an IIS server, or even one of those new Macintosh servers and have it
run without having to change a single line of code. Try doing this
with Perl! Its as though it was written in assembly, Perl requires
that much rewriting.
- Graphics. PHP comes with a nice little graphics library. While I
wouldn't use its to code the new Doom (VB would be a better choice)
its adequate for most web pages, and should be considered as a
substitute for Flash for certain things. Perl lacks a graphics library
of any kind.
- Data Structures. Under PHP you can create any type of datastructure
you need: Linked lists, binary trees, hash tables, queues, inverse
Reiser-biased recursion trees, etc. Under Perl you're extremely
limited in what you can do. This is because Perl isn't OO (so you
can't create Node classes, for example, usefull in a linked list) and
because it lacks pointers. Some of you may notice that PHP lacks
pointers, but look deeper! Behind the scenes, hidden from the user
pointers are used. Because of this, PHP can support complex data
structures.
Again this is just my experience. I don't mean to offend any Perl coders because Perl was an excellent language. However, in certain cases it may behoove one to write the back end in PHP instead of Perl./. itself may not be, but PhpSlash is. Also, I suspect the reason the slashdot crowd likes PHP so much is due to (among other things) a couple of reasons:
1 - It lets you mix html and code in. Sure, it's not the only language that lets you do it, but it's still a strength.
2 - It's free, open source (zend crap excluded)
3 - Microsoft hates it. That's always a plus.
4 - It's increadibly flexible and forgiving. Coming from a c background, this is one of it's most useful features to me. As far as I can tell, most programmers are inherantly lazy; They don't want to work harder than necessary to do a good job. In PHP, types are incredibly loose. If you want to use a string as a integer, a float, and a string all in the same line, you don't have to cast it. It just does it, and the incredibly vast majority of the time, it does just how you expected it to. Why can't C be that smart?
Contact Me (got tired of viruses emailing me).
You bring up some good points but here's a thought I have regarding your first suggestion. Why have a function like SetDBType built in when it can easily be accomplished with a simple include file that specifices the type of database you want to connect to? That way an application only has the database type hardcoded in one place for an entire application. As we can see by C, giving the end programmer a smaller set of tools that always works is better than giving the programmer thousands and thousands of built in functions. I mean, that was the reason for the move to RISC processors after all. Giving everyone these functions that only apply in some situations often just leads to unused functions. Although these types of issues can be more of a problem in a language that is much closer to the hardware.
DID YOUR MOM SERVE YOU AN EXTRA HELPING OF DUMB TONIGHT?
PHP 5 will have much much better XML support.
There is a lot of work on a complete new DOM extension, which should clean up the mess done in domxml as of PHP 4. It will follow the W3C DOM API as much as possible and is completely rewritten from scratch.
Furthermore Sterling Hughes is working on SimpleXml. An extension which should make it much easier to access XML Documents with the usual PHP functions.
The SAX Parser in PHP 5 will also be based on libxml2 and not anymore on the aging expat library.
XML Validation, XPath and XSLT support are also currently revised and should be improved a lot in PHP5.
it seems to me that most advocates of perl think perl is better than PHP, and vice-versa for PHP advocates.
:D
The stigma that is associated with perl is generally that "its harder, more lines of code, doesn't have the same functionality" because it takes a steeper learning curve. With PHP you can pretty much do anything right away: just search for the right function. I bet if most big PHP developers gave perl a chance, they'd be surprised.
Same goes for the other side, however. Since PHP is easy to get started on, there are a lot more PHP newbs than there are perl newbs. This reflects poorly on PHP developers as a whole, which there are obviously some very talented ones that don't deserve said reflection. I think the big thing in PHP is "controlling the beast." It can easily become insecure, inefficient, etc. if you don't know what you're doing..and the abundance of newbs make it appear like this happens all the time.
Anyway..I just ran outta pennies..