Slashdot Mirror
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.
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.
I've got the Perl cookbook, and have used many of the source code samples found inside in my work. However, most of the development I do is PHP, and I'm extremely excited to hear that they've released a cookbook for PHP. I reccomend this and the Perl cookbook to any developer who wants advice or inspiration.
Matthew Walker
http://www.tweeterdiet.com/ - My Diet Tracking Tool
1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?
.NET support?
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.
I'm a PHP/MySQL junkie, and every time I see anything about PHP on
</rant>
Im dreaming ofa big bndwdth, That can resist the
I actually bought a copy of this book, as well as the other one referenced in this review. I found them quite useful in learning PHP - the examples can be easily tweaked to create useful little applications. I haven't done very much with web programming except for few CGI-scripts and PHP definitely looks much easier way to create useful applications.
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!
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.
Contact Me (got tired of viruses emailing me).
This book has been out for nearly a year. Is this news?
Since the "language of browsers" is ECMAscript it makes sense to use that on the server, too, so one doesn't have to constantly shift back and forth between languages.
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.
Mike van Lammeren
It will challenge your head, your brain, and your mind.
*Obligatory PHP flame from the Perl Guy *
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.
bp
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?
My Karma was at 49, then they switched to words. All that work for nothing!
to see a book that deals with advanced application design in PHP. The problem with PHP is that most PHP developers are amateurs who don't know the first thing about app design. At best, apps are written with objects used randomly to accomplish some tasks and mostly include files for 2 dozen reused functions (or functions that aren't even reused, but still included in every page).
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.
The global economy is a great thing until you feel it locally.
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.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
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.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS