Professional PHP4

Henry Birdwell contributes the following review of Wrox Press's Professional PHP4. Read on for his impressions, and to see if this book is right for your own dynamic web programming tasks. Professional PHP4 author Luis Argerich et al pages 975 publisher Wrox Press rating 9 reviewer Henry Birdwell ISBN 1861006918 summary Comprehensive print resource for working PHP programmers.

PHP is an open source server-side HTML-embedded web scripting language for creating dynamic web pages. Outside of it being browser-independent, PHP offers a simple and universal cross-platform solution for e-commerce, complex web, and database-driven applications. Professional PHP4 will show you exactly how to create state-of-the-art web applications that scale well, utilize databases optimally, and connect to a backend network using a multi-tiered approach.

Almost an year since its release, this book has stood the test of time, and proved to be what it promised -- an up-to-date, advanced book on PHP -- a category in which there are very few worthwhile entries to date.

It provides a solid, fast-paced drill on the rudimentaries of PHP (although the fast-paced installation instructions come in the form of classic compendia -- worth 100 pages) for seasoned programmers, before it plunges head straight into the more advanced areas of the language. Each chapter reads a bit like a tutorial on a particular area of advanced PHP development.

If you are a competent programmer in just about any other language or have grappled with HTML before, then this book will teach you PHP from scratch . It will also introduce you to many of the more advanced areas of PHP programming, and is a treasure trove for information on diverse tasks possible with the language.

Notable topics include:

• Object Oriented Programming
• Sessions and Cookies
• Coding an FTP Client
• Sending and Receiving Email and News
• Networking and TCP/IP
• Non-Web Programming (including GTK)
• PHP and XML
• PHP and MySQL/PostgreSQL/ODBC
• Security
• Multi-tier development
• Optimisation

The code for the examples presented in the book is available for download, from the publisher's web site.

Although this book is reasonably complete, it lacks sufficient depth for experienced PHP developers who want to wade into the depths of specific PHP related tasks. Having said that, the publisher has provided information (of course at a separate cost) on specific areas with their second level PHP titles -- Professional PHP4 XML , Beginning PHP4 Multimedia Programming , Beginning PHP4 Databases and Professional PHP Web Services .

Suffice to say that the book has packed together a lot of diverse information (in 975 pages).

Related Links

• The official PHP web site
• Zend - the PHP scripting engine

You can purchase Professional PHP4 from bn.com. (You may also be interested in the Slashdot review of Professional PHP XML of a few months ago.) Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

PHP5?

[Synn]

Does anyone have links to news/features on what's supposed to be in PHP5? I've been hearing rumors that it's going to be much more object oriented and easier to do serious design work in.

Re:PHP5?

[tolan-b]

Yes it's going to be much more object-oriented.
Handy stuff like:

+passing by reference by default (rather than having to prepend ampersands all over the place)
+multiple inheritance (i don't think this has been confirmed yet, personally i'd prefer something like java's interfaces, but that's because i love java ;)
+private member vars (again not confirmed yet afaik)
+static member vars
+exception handling! yay!
+deletion of objects that are still referenced (optional of course ;)
+dereferencing of returned objects
+object cloning
+destructor methods

and.. well loads more, but if you want lots of detail go read the pdf ;)

all quite exciting if you ask me. the one thing that has always frustrated me about php is it's partial OO support, and I think this will go a long way to fixing that. i can't wait.

Re:Using PHP on a professional site

[onion2k]

Yahoo recently started using PHP to run their site. PHP is not just another toy language to tinker with, its a very capable tool. Don't confuse 'easy to use' with 'not powerful'.

When you make a complete enterprise site, you use the language that will give you the most advantage for maintainability and design.

Exactly. PHP often fulfills that need.

This book is great

[mr_z_beeblebrox]

PHP is a great solution for small to mid size businesses. Designing server based database apps is easy and they can run on Linux/MySql (duh!) which is a great kick in the TCO for a small/mid size biz. While I agree with the earlier flame regarding PHP in the enterprise I do think it works pretty well for business apps just not with thousands of users.

One thing I feel is missing is the ability to USE the host system. If I could access serial devices for example I could have a pc as a database server and one as a cash register, then I could have a serial based cash drawer at the PC being controlled by the server (this is a fairly common POS setup) this would be very useful. (I know I can use Perl to do it)

Re:This book is great

[LostCluster]

PHP is intended for run-in-the-browser apps, and really does not have much in the way of support for anything that doesn't. In exchange for direct functions to send HTTP headers and cookies, you basically give up the ability to "control" the host computer.

PHP is not a be-all language, and it'd turn ugly quickly if they tried to force it to be one.

Re:Using PHP on a professional site

[Synn]

I've been using php for about 5 years professionally and have actually been looking into using Java, mostly because I'm interested in the concepts behind MVC design.

But one of the things php has given me over the last 5 years is total rock solid stability. I mean, I've hacked up some complete crap code over the years but I've never once had a php related crash(and apache only ever crashed when we tried integrating Cold Fusion into it).

In testing Java servlets I have gotten out of memory errors in a database app I've written, but that could very well have been a lack of knowledge on my part(maybe I had the server misconfigged). I'm reading up more on admining/designing for Java now and will do more serious tests in the future.

But don't dismiss php as a toy language. The code you create can be messy, but it's rock solid stable. 5 years of 80k+ lines of code without any crashes is nothing to laugh at.

whats new?

[WrongWay]

So whats new in this edition?? Whats diff between the professional PHP 4 book I bought like 2+ years ago , and this book?? or is this just an insanely late book review???

Re:Using PHP on a professional site

[FortKnox]

Actually, I thought they migrated using PHP for background scripting, not on actual pages that are displayed (I think they still use a proprietary C system).
Of course, this is all out of my memory, not actual links.

Funny thing is, I wasn't gonna start the "J2EE vs PHP for professional site" flamewar, and then someone else goes and starts it.

And PHP doesn't have the greatest OO built in that most architects drool over.

I agree to a certain extent

[Twister002]

It depends on what exactly the enterprise size app is doing and what it needs to connect to.

For example, an enterprise wide phone extension list could easily be done using PHP instead of Java.

A complex work-flow application might not be the best fit for PHP. A whiteboard collaboration tool definatly would not either, PHP-GTK not withstanding. :)

I've used PHP to call both Java and VB COM objects on the same page. I had to work with two different groups in a company, one used Java, the other used VB. It was easier to use PHP than to write a wrapper for either.

Up to date one year later?

[dcuny]

Almost an year since its release, this book has stood the test of time, and proved to be what it promised -- an up-to-date, advanced book on PHP -- a category in which there are very few worthwhile entries to date.

So the book is still up to date, even an entire year after it's release?

Something's wrong here... Those php people better get on the ball and start releasing more often! The only language I know of that's stays that stable is COBOL.

No point in playing with it, unless it's the latest bleeding edge, crashing and burning on a regular basis. On my Windows box, that is - my BSD box remains rock steady.

Nope, still not funny.

Please listen up to my noteworthy advice

[SteweyGriffin]

We recently switched from perl to PHP. Perl seems to be much better and handling file manipulations and it definitely is more a more complete language. But developing in PHP is so fast that the switch was easy.

With PHP, the default "thing" in a file is html that it just spits out. You have to do something special to make PHP code to run. So if I configured my server to handle .html with cgi-bin/php, all of my pages would still be served fine (although slower if run as a CGI.) What this means is that our layout people can design pages and we can easily put in code after the page design is done to make it look just like they want it. If they then want to move stuff around, they can (for the most part). They can even use editors like frontpage (and it won't complain about the php code if you use the code delimiters.)

Also, with PHP you can also do things like this:
<? if (somthing) {?
Something was selected
? } else { ?
Something was not selected
? } ?>

so when I am printing out large chunks of html based on some variable, I can just use html without messy prints all over the place. Of course, you can use perl "print EOP" type statments, but I think the PHP approach is more elegant.

Also, the fact that PHP takes care of all the variable collection was a big plus for me. I just type testing.phtml?id=2&name="jeff" and sure enough, $id=2 and $name=jeff. Obviously, you can do the same thing in perl and it's not terribly difficult. But in PHP it is just that much easier and it's one more thing I don't have to worry about.

I would strongly recommend that you at least try PHP for a simple mail form or something. I think you'll fall in love with it for web stuff. And if you're doing database work too, then I think you'll really like it.

Re:PHP5 soon, no?

[vladkrupin]

It's not hitting the net anytime soon.

PHP 4.3 is still in the midst of release cycles, and things aren't perfectly smooth, as always. Chances are it won't be out for another few weeks (a month or so is probably a safe guess)

PHP5 will be ready... well, when it's ready. Nobody even started thinking what should go into PHP5 yet. Aside from Zend2, which you can use already with PHP4 tree.

If you have a big feature - ask for it, but currently there is nothing that is groundbreaking enough to even start working toward version 5.

A Criticism Of PHP5's Namespaces (plz read! :)

[mccormick]

Actual, the current work to implement a cross between multiple inheirtance and Java-style interfaces is in the form of delegates, but I'm not going to talk about that here.

I lurk on the php-dev mailing list, and one thing that I'm worried about with respect to the direction PHP5 is taking is the support for namespaces. The latest preview alphas of PHP 4.3.0 with Zend Engine 2.0 (as opposed to ZE 1.0, which powers the latest stable version, PHP 4.2.3) has demonstrated some of the above features in action (but they are, of course, still in-development.) The current 'implementation' (and I'm using that word loosely) of namespaces/packaging is something called 'nested classes', and let me assure everyone of the following: Zend Engine 2.0's "nested class" feature do nothing for implementing useful namespacing! Nothing!. They don't even work for logical things you would think they would. With nested classes, only the parent class can extend any other, and the nested ones absolutely cannot! Example:

class Parent { /* think of this as a 'namespace' level, which you'll see is still useless */
class Nested extends OtherClass {
// ..
}
}

Even the latest from-CVS snapshots (cvs co php4-ze2) crock with a very specific error message: "Nested classes cannot inheirit." So how exactly do these help in namespacing? They don't.

Even the following like seem like a logical ability for nested classes, but ZE2.0 just doesn't support it:

class SqlDatabase {
/* consider this to be some kind of generic database access class, extended once per RDBMS; see below */

class Connection {
/* handles connection management; implementation omitted (it's just an demonstration of something useful for nested classes that PHP doesn't support at the moment) */
}

class Error {
/* imagine the new try..catch exception capabilities throwing this kind of exception, that is, Database::Error; ideally it would contain detailed error information and easy ways to programmatically understand what it means (if it is just a warning, a fatal error, connection error, etc.) */
}

class ResultSet {
/* holds the results of queries */
}

/* ... and et cetera.. more as applicable */
}

/* let's consider a hypothetical RDBMS implementation -- just names for now */
class MySqlDatabase extends SqlDatabase
{
class Connection { .. }
class Error { .. }
class ResultSet { .. }
}

So, hopefully the above looks like a start, and, of course, this would provide the necessary generic interface so that other RDBMS could be implemented according to the same mechanisms. However, the above doesn't even begin to work as expected in PHP with Zend Engine 2.0.. In the MySqlDatabase class, we might see a nested class like 'Connection' and think it would relate to the parents' subclass by the same name. So, using condensed symbolisms, like this:

* P is parent
* P defines 'n' as a nested class (P.n)
* C is child of P (in PHP, 'class C extends P ..')
* C defines 'n' as nested class (C.n)

I would propose that it would make sense that 'C.n' implicity extended 'P.n'. That could be useful, for example, in the above database example: a single root class, SqlDatabase, could provide a variety of interfaces that are grouped together and not disjoint. So not just a bunch of related classes like MySqlError and MySqlConnection but a single MySqlDatabase class (with nested classes) that implicitly in the language relate the nesteds' amongst themselves.

But nested classes are not namespaces. PHP needs a syntax like that of Java mixed with Python, and, being a scripting language, PHP should allow namespaces to be first class language objects that can be manipulated, and they should have clearly defined scoping rules. Example:

package php.example;
/* semicolon could mean all the follows is in this package; scoping rules would need careful definition */

class Test {
/* the explicit full reference to this class would be 'php.example.Test', but any other classes within this package scope could just call it 'Test' */
}

package php.example2 {
/* using the brace notation would only include what's within the braces, and if we're in a broad semicoloned one like above, this section would be treated separately, but anything afterwards, until either the end of another single-statement 'package' directive would be implicitly in 'php.Example' */

class Test {
/* no name collisions with the above because this is 'php.example2.Test' and it is 'php.example.Test' */
}

class Test2 extends php.example.Test {
/* this stuff could be really useful to PEAR */
}
}

package php.example3 {
import Test from php.example;
/* now class definition or code can make reference to 'Test' from the php.example namespace */

class Test2 extends Test {
/* no name collisions between this 'Test2' and that of 'php.example.Test2', yet 'Test' seems like its local thanks to the import above */
}
}

I admit that the scoping rules could be tightened. For example, after a broad 'package x;' statement, what if you wanted to define the contents of a subpackage using the 'package y { }' syntax but wanted the 'y' namespace to be under 'x' (so that anything defined in y would be prefixed globally by 'x.y.')? Edge cases like that would need careful consideration, and the only thing I can think of at the moment is a separate 'subpackage' keyword that would work in conjunction with 'package x.y.z;' definitions to consider 'subpackage w' to be really referring to a 'package x.y.z.w' definition.

I just want PHP to be even greater because I love it. I am working to document some of these ideas and the make the case for some more of these kinds of additions to the language, as well as coding the patches against ZE2.0. If anyone would like to share their ideas with me or help me work on this, please feel free to email me at pete (at) petrasync (dot) com (and sorry for some of the misformatted code blocks -- they are a tad difficult to get right.)