PHP Cookbook 238
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
- 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.
Buy a Book v.s Web Resources (Score:5, Insightful)
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 [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.
The Cookbooks are wonderful! (Score:2, Insightful)
Things PHP is missing (Score:4, Insightful)
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)
In short, PHP is a good language for small projects, but just doesn't cut it in an enterprise setting.
Sick and tired of this (Score:2, Insightful)
I'm a PHP/MySQL junkie, and every time I see anything about PHP on
</rant>
Good learning tool (Score:2, Insightful)
The examples of integrating to MySQL were especially useful as I have been playing with Microsoft Access using MySQL as server, and now I can easily create web views from the database!
Re:PHP Security (Score:5, Insightful)
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.
News? Publish date = Nov 2002 (Score:2, Insightful)
Re:Speaking of FUD (Score:3, Insightful)
That doesn't even remotely make sense. Most browsers have javascript built-in, so that should decide what language to use server-side? Personally, keeping javascript for client-side and PHP or whatever for server-side is less confusing. That contextual switch is easier when the client-side / server-side code looks different.
Now I'm off to find a review of a Javascript book, so that I can insert random comments about what a shitty little language it is. That will be quite helpful for someone who wants a book about Javascript, I'm sure.
All PDF generators suck (Score:3, Insightful)
Of course unlike Perl there are no easy/good ways to create one in PHP
*/Obligatory PHP flame from the Perl Guy*
There are no good ways to create one in any language. Current solutions are either:
(1) A thin shell over text and graphics primitives
or (2) dependent on an external rendering engine which creates another format like Postscript.
I'd like a high-level PDF creation library that would let me, say, directly create a table that is sized to fit the contents like HTML, but unlike HTML, will split the table across multiple pages, repeating header and footer information. Sounds straightforward, right? Not possible now. I've checked with Adobe engineers, and it's not even possible with their $20K PDF generation toolkit.
I can just hear the XSL-FO people saying, "but it IS possible with XSL-FO." And it's also possible, given all the sand and steel you could possibly need, to build a window. Point is, it's currently way too much trouble. I'm sure it'll get there eventually, but PDF creation is really an idea in its infancy right now.
Re:Speaking of FUD (Score:5, Insightful)
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?
I'd give anything (Score:3, Insightful)
At worst, every database connection is hard-coded in a different place and there are no comments anywhere.
In either case, my God help anyone who wants to add functionality. These same people need a good book on relational database design, or be subjected to 4 years of universigy RDBMS design courses like I was. IMO, if you aren't willing to slit your wrists to get out of an RDBMS design class, you haven't taken enough of them.
Re:Buy a Book v.s Web Resources (Score:3, Insightful)
'web apps' (Score:3, Insightful)
I think a large part of the problem is that PHP is illsuited for many of the larger web applications it is being used for. Traditional Application Server features such as tag libraries found in JSP, ColdFusion, etc. would be good for separating the 'coders' from the 'presentation designers' in large projects, but that's not pertinent to security.
What gets large PHP web applications like web based mail user agents, like Squirrelmail, and content management systems like PHPNuke is that they have to keep a lot of temporary resources between user actions in a single session. Resources such as open files, sockets, variables in memory, for instance.
PHP's simple engine, and its lack of language features to support these features forces PHP web application developers to build and destroy many of those resources in the life-cycle of the script instead of the life cycle of the application or the user session that is more appropriate.
The larger the application gets, the more difficult it gets to build using the simple 'web scripts' programming paradigm PHP and Perl pushes developers towards. This affects security and performance.
The end result is heavy dependence on databases for variable persistance and error-prone algorithm concoctions, a la PHPNuke et. al.
Re:Ain't php great? (Score:2, Insightful)
Well, it'll be a module, not a built-in; Perl's built-ins are often powerful in the broad thermonuclear sense, but are never web-specific. Two key differences remain, though.
One: The Perl modules will have 15 dependencies each, 3 of which are no longer available at CPAN and which have to be hunted down from a Taiwanese mirror using archive.org.
Two: The various Perl modules you need will use different and incompatible pet data structures as preferred by their various developers, so you'll spend extra time writing glue code - vs PHP where you just use the function and go.