PHP 5 Power Programming 218
| PHP 5 Power Programming | |
| author | Andi Gutmans, Stig Saether Bakken, Derick Rethans |
| pages | 720 pages |
| publisher | Prentice Hall/PTR |
| rating | 9 |
| reviewer | Mary Norbury-Glaser |
| ISBN | 013147149X |
| summary | PHP 5 Power Programming |
Chapter 1 sets the stage by asking "What Is New in PHP 5"? The chapter begins with a quote from John Scully: "The best way to be ready for the future is to invent it," which perfectly describes the authors: Andy Gutmans and Zeev Suraski have continued to push the PHP project to improve on the original foundation and to add cleaner programming enhancements. The leap from v.4 to v.5 is no exception, as this new version has brought singular advances: OO programming with PHP enjoys a leap forward in focus with a complete redesign of its object model, a completely re-written MySQL extension (MySQLi), support for SQLite, a new mechanism for handling errors via exceptions, a suite of re-written XML extensions based on the libxml2 library, a C-based implementation of SOAP and a new memory manager.
Following this tour of the new features of PHP 5, the reader is exposed to a brief chapter on the basic language of PHP. An experienced developer can skip this chapter, but it's a very good overview of the syntax including variables and superglobals, basic data types (integers, strings, booleans, arrays, constants), operators, control structures (conditional, loop, code) and functions.
PHP 5's OO support is the subject of Chapter 3. Object oriented programming was introduced in PHP 3 but it was in an extremely elementary form and while it was improved upon in PHP 4, it truly comes into its own in PHP 5. Covered in this chapter are the basics of the OO model, object creation and lifetime, access restriction keywords and the benefits of using class inheritance, as well as tips for exception handling.
Chapter 4 is a well written chapter on advanced OOP and design patterns (strategy, singleton, factory and observer), with some very good code examples on iterators and the reflection API, which allows the programmer to collect information about his or her script at runtime.
Chapter 5, "How to Write a Web Application with PHP," is an excellent fusion of code and best practices in developing a complete dynamic web application based on PHP. The concept of good design practices is often overlooked in "how-to" manuals. Rather, many technical books focus on overcoming code issues and avoiding pitfalls associated with poor code execution. Here, the authors take time out to detail techniques on making scripts "safe" ("trust nobody, especially not the users of your web applications"). Bugs and security holes are a fact of life, and this chapter covers some very practical techniques to avoid consequences arising from weirdness caused by users as well as from deliberate attempts by bad guys to crack a site's security.
Databases are covered in depth in Chapter 6. SQL and SQLite are discussed (each with a section on strengths and weaknesses) before examining the new database-connectivity features of PHP5 using mysqli and sqlite extensions. PEAR DB is also presented, with a section on the pros and cons of using a database abstraction layer like PEAR DB. Connections, queries, fetching modes/results and other topics are well covered. I would have liked to see some additional discussion and implementation of SMARTY in this chapter. SMARTY is a template engine with an ability to cache templates into PHP scripts which saves on overhead and contributes to speed and efficiency.
Error handling is the topic of Chapter 7. Types of errors (undefined symbol errors, portability errors, runtime errors and PHP errors), PEAR errors (PEAR_error class, handling of PEAR errors and PEAR error modes) and exceptions (exceptions explained and the specifics of using exceptions) are treated adroitly.
"XML with PHP 5" in Chapter 8 will undoubtedly become a focal point of the book for many readers. Along with the addition of support for OO programming, using the new XML extensions are some of the most exciting developments in PHP 5. The XML implementation is standardized on libxml2, compliant with W3 standards and extremely efficient. This chapter introduces XML in PHP 5 with sections on the vocabulary of XML, parsing (SAX, DOM, XPath), the SimpleXML extension (very cool, because this allows the programmer to access the XML through a data structure representation, treating the information as objects), PEAR classes that deal with XML (XML_Tree, XML_RSS), converting XML and communicating with XML (XML-RPC, SOAP). PHP 5's new SOAP extension is a welcome improvement over previous PHP versions.
Following this excellent chapter is one on other valuable mainstream extensions: files and streams (I/O streams, compression streams, URL streams, locking, renaming and removing files, temporary files), regular expressions, date handling, graphics manipulation with GD ("gif draw" to old-timers, "graphics draw" to the youngsters) and multi-byte strings and character sets. This is a solid chapter encompassing the wide range of functions that are intrinsic to the core of PHP to the many favorite and practical extensions that are outside the core of PHP.
Chapters 10 through 12 deal with PEAR: installing PEAR, commands, packages and components. Stig Bakken's extensive knowledge and experience is obviously prevalent here. It's worth noting that you won't find a better single coverage of PEAR and PHP 5 anywhere else.
For those readers experienced in PHP 4 and who are looking to move to v.5 and are wondering what to expect during the transition, Chapter 13, "Making the Move", will be of particular interest. The authors suggest that in migrating to PHP 5, "you can encounter some minor incompatibilities" and address a number of these: using compatibility mode to revert to PHP 4 behavior, recognizing script problems using OO features and learning the new names and locations of files in the PHP 5 distro, among others. Users of PHP on the Windows platform may want to spend some time over this chapter (and maybe reconsider their choice of development platform!).
Designing for performance is the subject of Chapter 14, and the authors encourage the reader to plan for optimal performance during the design phase: benchmarking, profiling with Zend Studio's Profiler, APD (Advanced PHP Debugger) and Xdebug, using APC (Advanced PHP Cache) and ZPS (Zend Performance Suite), optimizing code using micro-benchmarks, rewriting in C and writing procedural versus OO code. This extensive chapter offers the reader a fairly complete set of tools and sage advice for more efficient design.
Chapter 15 is titled "An Introduction to Writing PHP Extensions," and introduces the extension API that allows developers to write custom PHP extensions. This isn't a chapter for everyone, since there are already a large number of available extensions and, as the authors note, unless you need to wrap an existing C library to give it an interface from PHP then you can easily skim or skip this chapter entirely. Note, though, that memory management has a section here and it's worth a read because of PHP 5's support for multi-threaded environments.
The final chapter of the book is called "PHP Shell Scripting," and explores the CLI SAPI (command line interface Server API). There is an introduction to PHP CLI shell scripts (how CLI differs from CGI, the shell scripting environment, parsing CL options, good practice) with some nice examples.
Appendices on PEAR and PECL (PHP Extension Community Library) Package Index, phpDocumenter format Reference and Zend Studio Quick Start Guide complete the volume.
The authors succeed in providing an excellent manual for "power programming" in PHP 5. There is terrific guidance here for many PHP developers and experienced Java, C++ and C# coders who are looking to either migrate to PHP 5 from v.4 or who are looking to gain experience in PHP programming. The experience the authors bring to the table is indisputable and their style of writing and the ease with which they bring new language and tools to their audience is admirable.
You can purchase PHP 5 Power Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Upgrade to 5 (Score:1, Interesting)
On Windows? (Score:1, Interesting)
Re:Upgrade to 5 (Score:4, Interesting)
Re:php5 (Score:2, Interesting)
I try to apply that Test when I feel dumb for putting stuff on my resume'.
Coldfusion still wins my heart (Score:3, Interesting)
I was *shocked* when I found out PHP projects are coded for a specific database. In Coldfusion I can change database vendors merely by making a change on an admin page. All the Coldfusion code remains the same. Of course of you have to avoid non-standard SQL inside your queries.
Is PHP database support anywhere near Coldfusion's?
Not trolling, just would like to know.
Re:php5 (Score:5, Interesting)
For instance, I was actually asked to do an application for a client where scripting language and platform hadn't been decided. the mini-app had to generate images on the fly, include a search-engine style capability, etc. In ASP-land, I'd have to use an external DLL for the images and buy a searching script. In PHP-land, I used the built-in graphics library and phpdig. Although I think ASP.NET has its own built in graphics libraries, its simply much much harder to find free code for it. I know that might be an anathema to some, but why re-write barcode generating scripts or search functionality when a good alternative has already been written?
OO at last (Score:3, Interesting)
I am personally of the conviction that OO is among those things that are absolute necessities to keep the work of mediocre (sloppy) programmers like myself moderately sane and structured, as soon as the number of lines exceeds throwaway level, say, 10,000 lines or more. I can't read my own code, let alone that of somebody else, if it's more than 10,000 lines and doesn't have a good class diagram as its basis, unless some other methodology was used, and those other methodologies are more problem specific than OO.
Now I've seen (and luckily enough, managed to largely stay out of participating in) a project that was done in PHP4. Honest attempts were made (I swear) to separate user interface from business logic and to implement the latter in terms of an OO class design, but PHP wouldn't even let us *pass references as function arguments* without complaining. Which meant the OO support that was there was little more than shallow imitation. Which basically meant we couldn't implement the class design because the language wouldn't let us.
As you may have guessed by now I'm also a fervent advocate of strong, static typing so I wouldn't trust myself with PHP 5 anyway, but it's good to know that they have at least managed to pass the hurdle of knowing what a reference is. It is (truly!) remarkable to see the power of open source in PHP, which has grown from a dirty hack of a Perl script to improve upon the even worse hack of Apache SSI, into a full-blown programming language, and I'd regard it as past its adolescence. The reviewer rightly points out XML support as a particular area in which previous versions of PHP lacked maturity. So it's getting there, but if you ask me: where exactly, I'll reply: where Java, NET and possibly some other languages are today.
Flamebait???? (Score:3, Interesting)
Re:Upgrade to 5 (Score:2, Interesting)
Obviously all OO has a "this" (or similar) for self-referencing, however PHP5 *requires* its use for referencing class variables; it seems silly to always have to be explicit when standard scoping rules would apply.
You mean having a class initiate at the start without having to call upon it? Oh no! That's definately a step in the wrong direction.
It's obvious that a constructor is required for a class, I'm pointing out that it's silly to use __construct for the method name rather than the name of the class (as is convention in just about every other OO language and was what PHP4 used)
Re:The secret to PHP programming (Score:3, Interesting)
Software Evolves (Score:1, Interesting)
I can see how a language like C can be solid for a very long time. But the only time things don't change is when people stop using them.
In software we keep inventing new things and it is very prudent to document this newness. Hence we have new releases after a time so that the creators of these languages can give us better tools to use.
It isn't a bad thing.
And they need to make money so they write books.
I like this model of technical development.
Guess we have a lot to be thankful for when we live in an age that we can get free books in our house by typing wget in a command line.
Count your blessings and write a book of your own.
Re:Coldfusion still wins my heart (Score:3, Interesting)
There's another school of thought - opposite to yours and commonly encountered among experienced enterprise database application programmers - that says if you are not taking advantage of your database's features you are choosing to ignore some of the most powerful tools in your arsenal. This opinion arises from the fact that most large-scale "enterprise" applications are centered around a database schema. The database is not an afterthought, but rather plays a central role in the design and functionality of an application. In addition, a well designed database schema often outlives a single application and is commonly shared among multiple applications (I'm talking about business-critical data here).
The "database-abstraction" argument is not very well thought out: which tends to have a longer life span - programming languages or databases? Well, you never know for sure. In my experience, however, RDBMS solutions tend to survive two or three generations of new programming languages in large corporations. For instance, one certainly can't argue that Cold Fusion is likely to outlive Oracle. So why the emphasis on "swapping out the database" when this might entail giving up critical features such as stored procedures, triggers, views, domains, rules, schemas, etc. ? None of these features are "non-standard SQL" as they are all part of various ANSI specifications but they are hardly supported by all popular databases (MySQL comes to mind).
In answer to your question, use ADOdb or PEAR_DB if database interchangeability is a requirement for your application(s). If you're willing to trade solid relational design for the option to switch databases, you'll find it's just as easy to do with ADOdb as it is with Cold Fusion.
In our PHP projects, we use a custom database abstraction API but not so much for the purposes of easily swapping out the database. What I consider far more important is establishing standard database calling conventions in the code and providing automatic protection from SQL injection attacks (i.e. prepared statements plus database and datatype-specific escaping/quoting). This does have the side-effect of not littering our code with mysql_query(), pg_query(), etc. which would of course make it far easier to switch databases if the need did arise. Of course, we would also have to redesign the schema, re-implement stored procedures, etc. and, being good database architects, we might want to rewrite a number of queries to take advantage of the new database's features.