Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
PHP Books Media Programming Book Reviews

Professional PHP4 227

Posted by timothy from the lots-of-letters dept.
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 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.
This discussion has been archived. No new comments can be posted.

Professional PHP4 More

Professional PHP4

Comments Filter:

  • PHP5? (Score:3, Interesting)

    by Synn ( 6288 ) on Tuesday December 17, 2002 @01:07PM (#4908150)
    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? (Score:5, Informative)

      by Lordrashmi ( 167121 ) on Tuesday December 17, 2002 @01:11PM (#4908187)
      There is a paper on the ZEND engine 2.0 (which will power PHP5)
      PDF: http://www.zend.com/engine2/ZendEngine-2.0.pdf

      I would put the google HTML version of it, but it seems to be buggered.

      • Re:PHP5? (Score:3, Interesting)

        by tolan-b ( 230077 )
        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.

        • I've been trying to dig up info on the efficiency of using references in PHP4. The best I've come up with is "it depends, benchmark", which is good advice and all, but it's a bit counter-intuitive. I would have expected references to be generally more efficient. Somewhere in my searchings I came across a post by [one of the core PHP developers] that said something to the effect that references were very rarely more efficient, and in the next PHP release you should almost always avoid them unless you needed them for some other reason. I naturally forgot to bookmark it.

          Anyway, do you (or anyone else out there) have a helpful clue to share>

          Thanks....

        • 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.)

    • Re:PHP5? (Score:2, Informative)

      by Midwedge ( 617806 )
      At www.zend.com/zend/week/week114.php [zend.com]

      It says:

      PHP 5 not yet scheduled The number of messages to the list requesting some sort of schedule or arrival date for PHP 5 seems to be steadily growing. Please note that there are yet no dates for anything to do with PHP 5, and there still may be a whole new PHP (4.4) before the road to 5 officially begins. If there are any announcements to be made you will find them on either the main PHP web site (www.php.net) , or they will be covered here in this summary (I promise!).
    • In relation to PHP, OO is a programming style, not the underpinning of the language. PHP's strength is its simplicity, and the OO style rarely lends itself to simplicity for the average Joe.

      PHP5 will expand on the OO abilities of the language, public and private members, overloading (which is experimental in php4), etc.

      It might be worthy to note whats NOT going to be in PHP5, and thats the cruft extensions that have bloated it out to a 4MB+ download. Many of the extensions, except for the core stuff, will be moved to PECL.

      Also noteworthy is the advance of the PHP CLI, allowing use of the language in a more generic way with php based shell scripts. While this is available as EXPERIMENTAL in 4.2.3 and makes its stable debut in 4.3, I think it'll take off quite a bit in PHP5.

      Mike

      Ok ok, I'll be good. Gimme back my karma.
      • php4 is pretty good at cli stuff. if you know php well, and dont know perl or python well, you can still make useful shell scripts easily.

  • PHP5 soon, no? (Score:1, Insightful)

    by Strike ( 220532 )
    Isn't this book review a tad bit late considering that PHP5 is going to be hitting the 'net soon?

    • Re:PHP5 soon, no? (Score:2, Informative)

      by mrobinso ( 456353 )
      I doubt PHP5 will be available any time soon. The 4.3 branch is in a release cycle now (RC3). The Zend engine 2 is very much an alpha work in progress.

      I would think a stable release of PHP5 is still quite a ways off.

      Mike

      Ok ok, I'll be good. Gimme back my karma.

    • Re:PHP5 soon, no? (Score:3, Interesting)

      by vladkrupin ( 44145 )
      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.

  • PHP Website (Score:5, Informative)

    by TheFlyingGoat ( 161967 ) on Tuesday December 17, 2002 @01:15PM (#4908214) Homepage Journal
    I've said it before, and I'll say it again... the PHP website should be enough for anyone with basic programming skills. It's simple, clearly explained, and there's many examples and fixes posted by people. The only thing that would be helpful would be a PHP Cookbook that's as good as the Perl one.

    • Re:PHP Website (Score:5, Informative)

      by smack_attack ( 171144 ) on Tuesday December 17, 2002 @01:20PM (#4908261) Homepage
      Ask and ye shall receive [amazon.com]

    • Re:PHP Website (Score:1, Insightful)

      by Tablizer ( 95088 )
      (* the PHP website should be enough for anyone with basic programming skills. *)

      Yes, but not everyone can afford DSL or cable lines to have instant access. And, books are often easier on the eyes than screens IMO.
      • The major benefit of the php.net manual is the comments. I've gotten a lot of "extra" info from them that weren't aparent through the given examples. I've also contributed my own notes (and still get emails from time to time thanking me for an obscure problem with php/apache/slackware).

        As for requiring DSL, you must be joking... the pages are text, they load, you read... it's not like the manual is in streaming video format or anything. Jeez!

      • Re:PHP Website (Score:3, Insightful)

        by nahdude812 ( 88157 )
        Then they should download the downloadable documentation [php.net].

        Having never previously used PHP, the documentation here was actually more useful to me than the previous Wrox book, "Professional PHP Programming." But it's best as a reference, if you haven't done dynamic web programming before, you'd do quite well to invest in a wrox book, as I find them to be well geared at bringing you up to speed on a subject, and then serving as a good reference book.
    • Sure, you can get some things from there. It is not perfect by any means, though. I have the PHP4 Professional book, and I found it useful to get going. I don't open it anymore - I just go to the PHP site. However, I never could get myself started from the website alone (mostly a motivation thing, I guess).

      Some people prefer the style of books more than just the "definition" style of help files.

  • This book is great (Score:4, Interesting)

    by mr_z_beeblebrox ( 591077 ) on Tuesday December 17, 2002 @01:16PM (#4908226) Journal
    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)
    • 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.
      • 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.

        Bear in mind I am meaning access to functions on the server, not on the PC. You may well understand that but these days it can be iffy as to what people mean by host. PHP has a lot of good control functions and a lot of POS apps are run in the browser, hence my example. I feel PHP is rather well suited for that. A lot of people say it is a "perl replacement" to them I offer that if Perl can not do what you need, maybe a new programmer will help more than a new language :-)
        • With permissions set in /dev, you can't access and control system devices such as serial ports? Are you running PHP in safe mode? If so, you'll probably have to disable that.

          I've had only a little experience using PHP to talk directly to devices, but it's been successful experience. I should think you'd be able to pop open the cash drawer and stuff like that on the server with PHP using filesystem functions on /dev entries. Unless of course you're using PHP on Windows, then I'm sorry, but you bear the burden of a lower OSform.
        • Assuming mod_php as an apache module.
          Mod_php runs as apache (possibly under the name nobody) and can do anything to the server that apache can.
          Default installation will allow apache to read and write whatever is world readable/writeable, but that can easily be changed to whatever you need.
          Backquotes work very well in PHP (essentially the same as in shell scripts).
          While apache and php *will* run under Microsoft Windows, there are several things that work right on *nix and don't work right on Microsoft Windows.
          PHP and Perl are both very good general-purpose languages. Nothing will really succeed as a "be-all" language.
      • PHP is not a be-all language, and it'd turn ugly quickly if they tried to force it to be one.

        I don't think the PHP developers have any real intention to try and force it to be. However, besides using PHP for scripting web site db-driven apps, i've also found PHP (compiled as a cgi app) to be useful for writing scripts to be run by cron that need to easily tie in to the same database that runs the web site. I probably wouldn't try to write GTK apps in PHP, but building scripts that are not web-driven (but that interact with a web-driven system) in PHP (instead of say perl) has been handy, they can tie into your existing libraries and code.

        I can't really weigh in on the whole Java vs. Perl vs. PHP vs Python vs ASP vs ... debate, because I haven't done enough development in most of those languages, but I don't understand people who dismiss PHP off hand as being "only for rinky-dink personal websites".

        PHP isn't perfect, but it is fast, stable, feature-rich, and easy to develop web apps in. It certainly has its place in the toolbox, IMNSHO. The biggest thing lacking right now is good OO support. Right now it's clunky and sloooow. Zend 2.0 (when it's ready) should make great strides forward.

        • Re:This book is great (Score:5, Informative)

          by nahdude812 ( 88157 ) on Tuesday December 17, 2002 @03:15PM (#4909207) Homepage
          I can weigh in on that a little, having first learned and worked with ASP for 2 years before I got in to PHP, and having now been active in ASP and PHP both for that past two years.

          ASP vs PHP there is so completely no comparison. There is only one single thing that ASP does that is easier than in PHP, and that is application-scoped variables with out a database. I've written my own PHP classes to facilitate this, and although they may not be as efficient as ASP's memory resident access, they are just as useful.

          The hugely wide variety of functions PHP provides make programming a delight where you work more on your programming concepts and code flow than on authoring code. There are simply hundreds of functions available in PHP that I use on almost every page, that would require custom-written functions (that thus run as script, at lower performance than the precompiled PHP functions) that are simply not available in ASP. Try to do a join() or split() in ASP. Yes, it's doable, but with quite a lot of legwork. How about regular expressions? Searching, replacing, replacing with code execution, and more? Not gonna happen in ASP, nope.

          Then there are SIMPLE things that are HTTP standards that are simply lacking in ASP. For example, uploading a file. Gotta buy a plugin in ASP to do that. Or uploading creating an array of elements on a form. If you want to have an unknown number of entries in a form, in PHP, you can name the input fields, "field[0]","field[1]","field[2]" and they come in as an array. Or you can even name them "field[]","field[]","field[]", and they will come in as an automatically indexed array. Useful when you want to do things like add rows of input to a table with javascript, and have a script that easily handles the collection. Try to upload an array in ASP, and you have to write code that breaks down the field names to your liking.

          There are so many functions that I take for granted in PHP that I now have my own library of PHP functions rewritten in ASP so that when I am authoring in ASP, I'm not as limited by the language. Just try to do an md5 in ASP, or any other cryptographic operation though, I dare you.

          Ok, sorry, rant over, been working on an ASP for the past month solid, and I think I'm going through PHP withdrawl.
    • You could write the serial control mechanism in perl (or C, or whatever), then use system() (or related) [php.net] calls from php to poke it / read the output. Not elegant perhaps, but... The other option, since reading and writing to serial ports isn't exactly rocket science or a new thing, would be to grab some C source to do said, and wrap it into a PHP extension (which seems like a semi-easy process from what little I looked at it, if it were truly difficult there wouldn't be bazillions of php extensions). Honestly though, if you start doing hardware access to vital resources from php PLEASE FOR THE LOVE OF GOD make the server machine accessible only on the local lan. In other words, you might want JoeBob the store manager in the back office to be able to have a real-time web interface to moniter the sales line, but you wouldn't want to expose that interface to Dieter the 13 year old German 1337 h4X0r. ;-)
      • Honestly though, if you start doing hardware access to vital resources from php PLEASE FOR THE LOVE OF GOD make the server machine accessible only on the local lan. In other words, you might want JoeBob the store manager in the back office to be able to have a real-time web interface to moniter the sales line, but you wouldn't want to expose that interface to Dieter the 13 year old German 1337 h4X0r. ;-)

        Great info (regarding the serial mechanisms) and totally agreed regarding the above. POS apps are rarely on internet capable machines (at least so far)

    • So extend PHP (Score:4, Informative)

      by Ron Harwood ( 136613 ) <harwoodr@NOSPAm.linux.ca> on Tuesday December 17, 2002 @01:36PM (#4908377) Homepage Journal
      You can write your own extension (in C for instance) to interface with the hardware - and provide the PHP functions you want.

      See here [php.net] for details...

    • web forms are *not* simple (Score:4, Insightful)

      by Tablizer ( 95088 ) on Tuesday December 17, 2002 @01:38PM (#4908390) Journal
      (* Designing server based database apps is easy *)

      If you mean data input and query screens, I have to take some exceptions to that. Simple stuff is indeed simple in web apps. However, B-to-B and intranet managers often want GUI-like behavior from browser-based apps, and HTML+JS+DOM can turn into a tangled mess under such demands.

      The developer cannot just say, "well, this is an HTML browser, not a GUI, so it will not have all the functionality of a GUI", because that would be a half-lie. With enough effort and spahgetti code, you *can* make it do GUI-like stuff, but the code is usually horrible. The current standards are optimized for e-brochures, and NOT e-biz-forms.

      What is needed IMO is HTTP-friendly GUI browsers, using protocols like XWT and SCGUI (I'm still looking into Mozilla). (I rule out non-HTTP protocols because fire-walls often don't accept them. Some protest this, but I don't want to rekindle that debate here.)

      There is a huuuuuge need for such in my observation, and no vendor is stepping up to the plate. PHP could still serve as the server-side part of such a system, BTW.
      • Post or moderate? Hmm....

        I like PHP and web apps, and code a little here and there... but I must say that if you are designing a business app, security is of the utmost importance. Therefore, it seems to me that you can design a regular app (QT/$backend, or some other combination) to run on the server, and have the clients log in via ssh or something similar and have the app run on their desktops via port forwarding/X forwarding. This seems to me to be way more secure than SSL web applications, and eliminates the deficiencies you just mentioned.

        Ok, there are problems with this scenario (what if the user's connection drops occasionally?), and these would be hurdles to overcome, but my point is that while web apps are 1337, there are other more traditional and perhaps easier ways of making an app with the kind of gui that's needed for business apps

        • I have seen and heard about tons of problems, often political, of getting firewalls to work. One place had about 100 customers. The went HTTP because there were to many complaints about diddling with fire-walls.

          It is more "accommodating" to change your system to use HTTP than to ask 100 customers to play with their firewalls (and hire real firewall experts).
    • As someone who pretty much used the first edition cover-to-cover, I can honestly say it was a decent introduction book but it definitely lacked the details that would've made it really useful.

      Regarding the issue of using the host system:
      What about using the system through exec or accessing the system through system shell resources?

  • whats new? (Score:2, Interesting)

    by WrongWay ( 26772 )
    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???

  • Not Deep Enough (Score:5, Informative)

    by ze_lee ( 226318 ) on Tuesday December 17, 2002 @01:19PM (#4908254)
    I was going to pick up this book, based on the recommondation of friends (programmers) and online reviews, but when I thumbed through it in the bookstore, it just seemed...weak. Thin.

    This is PROFESSIONAL PHP programming, not BEGINNING PHP. Why even have the 100 or so odd pages on installation? This book is not targetted at newbies, it is for the serious developer. OK -- you're a J2EE dude who want to check it out; doesn't have PHP installed. Lots of references on the Web, and if you can't find them...you're not a Web developer.

    While the book probably would be helpful as a reference in some cases, I was just disappointed in it. The cookie/session section was a joke (and this is new in v4, so should be fairly rigorous).

    I didn't buy the book. And I like having references around. I have 7-8 open on my desk right now, from Perl through DHTML to PHP. Oh well, as people have noted, v5 is coming, so I guess we shouldn't get our packets in a bunch...
    • So you think it isn't a good Professional book. Is it a good newbie book? Even if it is poorly named? I not a programer but would like to learn and have been learning PHP on my own. Would this be a good investment or waste of cash?

  • Up to date one year later? (Score:3, Interesting)

    by dcuny ( 613699 ) on Tuesday December 17, 2002 @01:22PM (#4908282)
    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.

  • I have to prepare a report at my job discussing the merits of Perl and PHP and would like some ideas for good points to put across in favor or against either one.

    Personally I favor Perl as I think it can do much more but I'm not an expert by any means and I'd like to present some reasonable sounding arguments, possibly in front of people who are experts in Perl.

    Any ideas?

    Oh, and another question. I'm not 100% sure how Perl actually runs the Perl code. I know it gets compiled to P code, but I'm not sure at what stage this is done. Can anyone tell me how this works or give me a pointer to where I could find it?

    As usual, thanks for your help Slashdotters.
    • What are you going to be using the language for? That is a key deciding factor.
    • Given that:
      1. You already have a bias toward Perl, and
      2. You're talking to Perl experts, which means
      3. They're probably geeks and Slashdotters
      something along these lines should work:
      • "All right thinking coders will agree that Perl is the only language fit for the job."
      • "4 out of 5 ACs on Slashdot agree with me."
      • "Tolkien would approve of Perl. No wait, that was your other post.
      • "Does anyone want to spend another boring week in training?"

      OK, I didn't really have anything useful to write. I just like making HTML lists.

    • I switched from Perl to PHP early in my Web development days for a few reasons. Perl has an entire culture that comes along with it that advocates perl as the solution to everything, and that kind of thinking made made perl a pain to learn, especially for somebody that just wanted to write dynamic Web content, not rule the world with his regex talent. I was also annoyed by always printing out content headers and the CGI modules were clunky and had too much overhead.

      With that said, I feel that the top reasons to use PHP rather than perl are:

      • PHP's embedded nature as opposed to perl's stand-alone nature (I realize that perl can be embedded, but it's rarely used that way). This makes it easier to get simple code in to a page (just embed the code rather than creating an external file with proper permissions, header code, etc in the right location.
      • Simplicity of the language -- PHP is much easier to read and learn. This is so important when you develop a project with multiple coders involved or when a project needs to be taken over or maintained by somebody other than the intial developer(s).
      • Avoiding modules. PHP includes nearly all of the basics that you need for dynamic Web development and the extra code that you may need can just be tossed in to your code directories rather than installed as a module. This is nice when you have to deal with ISPs or server admins that are slow to install software and it makes it easier to move your code from one server to another.

      I realize that most of this won't convert a perl advocate (what would?) especially if they're going to be the sole coder on a project, but that's rarely the case with real production systems.

      Related links: Google: php vs perl [google.com], Web Automation: PHP vs. Perl vs. PHP [serverwatch.com]

    • To answer your question about how/when perl is compiled, it depends on the situation:

      • Command line or simple CGI program - your perl program is compiled each time it is run. This operation is much quicker than you might expect, but it's a painful amount of overhead for sites with tons of hits
      • CGI with mod_perl, minivend, other Perl based app servers - The Perl code is compiled once, when the web- or app-server is started. Compiled chunks of code are cached for later use after their initial compile. This is not done by the language, but by the environment, which is usually written in Perl (but can be written in C).

      As near as I can tell, PHP pages are compiled each and every time they are served, along with all the included code.

      • I'm no expert either, but there is some amount of cacheing of the compiled PHP on the server end. There are also a few PHP accelerators that probably do the same thing.

    • I've done a fair bit of development in both PHP and Perl (mostly web development, which is what I assume you're referring to). I'm not a PHP expert by any means, and I've been doing Perl for much longer, so take that into consideration.

      Perl is more succinct. Depending on your point of view, this is a good or a bad thing. You do need to acquire a higher proficiency with the language than is necessary with PHP in order to really make this useful, and to make sure that less experienced programmers on your team aren't confused. Things like use English; can help, but if someone really feels like shoving an evaluated regex into a map call, you can't stop them. (I feel like this often). I find that I often resent how much more typing I have to do in PHP.

      Perl is more mature. PHP is coming along rapidly, but things like recent major changes with super-globals and default config options (register_globals) do make it feel a little unfinished and slightly unplanned. They're just growing pains, but you still have to deal with them.

      This is also reflected in the documentation. PHP has pretty good documentation. Perl's is excellent. It's had a few more years to polish it.

      Debugging is much, much easier in Perl. The perl command line debugger is a great tool, and I wish PHP had something like it.

      If you don't have control over where it's going to live, PHP is easier to deploy. This is the single reason I use PHP almost exclusively for web development these days, and I hope this is addressed in Perl6. With PHP I can simply specify PHP version x and MySQL are required. If PHP is on the server, it's almost guaranteed that MySQL is and that's it's all hooked up nice. With Perl, if you need something that requires a C extension (eg, DBI), the host may or may not have it, depending on how much the admins like installing extra stuff. If you have appropriate access you can install it yourself, but if you don't, you're out of luck. Whether or not this is an issue for you depends on where your planning to deploy.

      CPAN. CPAN is marvelous. There is an immense amount of useful Perl code in there. If you want to do something, there's a good bet someone else has wanted to, too, and contributed it. The PHP community is working hard at building something like it, but CPAN has years on it.

      Regarding perl compilation - I was going to take a stab at it, but it's been too long since I've had to read up on it, and I'd bullocks up the details. If you have a copy of the camel (version 3) handy, there's a good section on it in there. Sorry, don't have a link handy.

      HTH

      • I agree with most of your post, but "Perl's documentation is excellent?" It works well as a reference for someone already familiar with Perl, but as an explanation of the language it's hideous. It's written as manpages, with names like "perlsyn," "perldata," and "perlre."

        The Camel Book, on the other hand, is great.

        But for electronic documentation, PHP has perl beat by a mile. It is organized, comprehensive, and user-annotated.

        • heh. Point taken. This is probably one of those places where my being more familiar with perl colors my opinion. It can be hard for someone new to it to find what their looking for in the pod. I still think that, once you've figured out where things are, it's generally more polished than the PHP docs. I often find those cryptic, and sometimes downright unhelpful. And the user-annotation on the PHP docs _can_ be great, but it can also be downright inaccurate. Not that I don't think it's a great idea, and I check it frequently myself. You just have to be careful with it. POD's got a long ways to go itself - it could learn a lot from, for example, the JavaDoc format. But I've always found the content very to the point and "expert friendly."

          Which is maybe one of the big differences - the perl docs aren't really meant for learning, they're for reference. When I'm in a hurry, they're just what I want. As always, YMMV.

    • when you pick php you have to be careful what you buy into... unlike perl, php is controlled by a vendor. php by itself is free, but if you want to do anything serious w/ it you will need zend optimizer which is about $2g per cpu (im talking 300% performance increase through caching etc). hey, mod_perl is free and it does basicly the same thing.

      performance wise, i think perl and php are on the same level

      i started out with php and then slowly moved to perl. i still have a lot of apps in php that i have to manintain once in a while ... and let me tell you - its major pain.


      php is really easy to learn and implement, but it lacks infracstructure. on the other hand, in perl you get away with a lot more things and its true that if you are not careful perl will get obfuscated and unmaintainable very fast.



      beauty of perl comes in when you put effort into developing strong infrastructure and stick to it. always use strict, -wt (warnings and taint mode). organize your code into neat modules (CGI::Application) and use a templating system (HTML::Template is very simple and wont let you clutter html with code). note that php doesnt have any of this features as readily available as in perl through CPAN modules


      when it comes to documentation, it might be true that php has good resources online, but perl has a lot larger comunity (check out perlmonks.org) i got replies on my questions within 30 minutes of posting!


      in short... perl has superior architecture to php, however php has better corporate support and better learning curve

  • Get over yourself (Score:3, Informative)

    by papasui ( 567265 ) on Tuesday December 17, 2002 @01:33PM (#4908350) Homepage
    Everyone that flames PHP needs to go sit in the corner and remember not to break their magic bubble of personal space. First the slashdot article is about the book not the language, second use whatever works for your needs. If PHP works for you and like it thats wonderful. If not use something else, there's a lot of other options.

  • Who needs a book? (Score:2, Informative)

    by unorthod0x ( 263821 )
    I've been using PHP quite heavily for a few years now; I never picked up a PHP book, not once.. Why? Simply because the community support, the IRC channel, the Online Documentation [php.net] and even places like devshed [devshed.com] simply have so much to offer! I have not even once printed or purchased even a mere shred of dead tree painted over with ink that describes or outlines PHP in any way whatsoever.
  • Now if only I could actually find a job where I could use it.

    Anybody? :-)

    -S
  • One - the book is OK, but out of date if only because of the 'register globals' stuff - they shouldn't have assumed it was on in a 'professional' book in the first place, imo.

    Second - shameless plug - we offer PHP training classes. here [tapinternet.com]

    Third - PHP topics always devolve into 'java/perl/.net/asp/cf is better than PHP'. Anyone who is interested in putting together serious multi-platform tests between PHP and other languages, please contact me privately, as I'd like to arrange something with other developers. Not as 'one language beats all' but to present some tests which aren't sponsored by the companies (MS, Sun, whoever) which obviously have a BIG bias as to how they want the results to appear. Having a cross section of multiple developers from multiple platforms agreeing to common test terms would help eliminate that, I think.
    • "Anyone who is interested in putting together serious multi-platform tests between PHP and other languages, please contact me privately, as I'd like to arrange something with other developers."

      That sounds interesting, and I would like to help. I tried contacting you via the contactus page on your website.

      If that doesn't work, it's easier to figure out my email address as it's anything @ sodablue.org. :)

  • Please listen up to my noteworthy advice (Score:3, Interesting)

    by SteweyGriffin ( 634046 ) on Tuesday December 17, 2002 @01:46PM (#4908458)
    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.
  • Has anyone worked with the Smarty templating extension? It seems like it would lead to better MVC use, but I haven't had time to use it yet. Will I be wasting my time?

    • Re:Smarty? (Score:2, Informative)

      by Anonymous Coward
      Smarty is excellent. Combined with DB::DataObjects from the PEAR suite (see pear.php.net) and you have a very powerful platform for rapid development.

      A rough outline of the way it works goes like this, you make your SQL schema and load it into your database, then you point DB::DataObjects at the database and it generates class wrapper files for each table. This by itself isn't fantastically useful, if you were just writing PHP the difference between using the class and using the DB PEAR stuff directly is pretty minimal, however its when you bring smarty into the picture that things get interesting.

      The reason is primarily because you can then pass the object you've retrieved from the database straight to smarty without thinking about it, within your template you can acccess the properties (Although not the results of methods, much to my dissapointment) directly, so *your* code doesn't need to worry about it, which means any time you want to add a new field to a table, you just add it in the database, run the dataobjects create script and then plonk it in the template, and it Just Works.

      The DataObjects create script is pretty smart, the class definitions that it generates are marked up with comments that give you flexibility to customise the class without risking the modifications getting overwritten next time you regen.

      Leaving you with only the "glue" PHP in the middle to write, the bit that handles logins, decides what functions need to be called to do what, and what page to display at the end of it. Believe it or not, smarty comes to the rescue here as well, giving you a simple mechanism to split up your logic and display operations.

      One of the primary problems with a PHP script is the switch statement. In the begining, people didn't give a rats about decent user flow, so every page was a different PHP script, and this worked fine except in the case of error conditions or multi-operators, ie, ok, I've just added the user, but now I'm stuck in add_user.php and I want to send them back to list_users.php. Some particularly object oriented people managed to get around this by having everything in classes, but it really didn't work well.

      Then came the switch statement, in the switch statement, everything effectively was in index.php, sure we had a lot of includes, each of which did a fairly specific thing, but in the end, all requests went to one script, and specified a mode or op or sequence or whatever you want to call it. This variable determined what was to be shown (ie, op=add_user), then, when add_user was done it'd call the list_user op equivalent somehow.

      The issue here was that the switch statement rapidly became the debuggers worst nightmare. Without a decent templating frontend, PHP and HTML became mixed into case blocks, includes were all over the place, and the amount of state to track mentally in any given place was horrendous. Decent programmers utilised standard methods to reduce the clutter but it still never really felt clean, go check out a lot of the PHP scripts available on the web these days to see what I mean, its pretty common.

      Another, small subset decided to use url redirects and the multi-file approach to resolve the same issue, they had the same problems but just confined to particularly ugly URLs and lots of page reloads.

      Recent advances and ideas have left us with a lot more options. Those who are still heavily OO are still running fine, they're not developing that quickly, but their code is ok, some of the more abstract programmers are doing ok on a task-by-task basis, developing entirely new structures as appropriate to the problem, but again, development time is the cost, and often a lack of code reuse means a lot of debugging.

      The MVC model is of course entirely appropriate to the particular problem, and what I suggest here is basically that concept although not explicitly.

      The idea essentially, is that for any page displayed, there are a number of actual "atomic" operations that need to be done. For a login page perhaps there are none, its just a damn login page. For a user edit form, there is the retrieval of the users details (and possibly a permissions check), for the page that actually does the update of the users details, there are the permissions check, the update, possibly the display of the original edit form with details filled in an an error message, or possibly the display of a user list with a message indicating the edit was successful.

      Always, at the end, we display a page of some kind, and we never do anything after that.

      We also never display more than one page, we might decide between two but we don't show more than one.

      Thus I construct my PHP apps like this:

      1. Require in DataObjects, Smarty, misc
      2. Initialise connections etc
      3. Retrieve session details if possible, otherwise get Guest user
      4. Define functional units, functions whose task is to *do* something. If these functions have anything to output, they $tpl->assign it into the template store, if they run into an error condition, they call the relevant display unit with the error message
      5. Define display units, these act as wrappers for the $tpl->display() call, displaying a particular template with all the data gathered so far
      6. Define the sequence switch, this is a switch statement on a variable, each element of the case blocks is *only* function calls, to any number of functional units, and finishing off with a display unit. Nothing else, just that.
      The end result? you have a list of operations, a list of pages, and a nice clean set of instructions on how to put them together. It is possible to extend this to handling error conditions in the sequence switch however without exceptions (coming in php 5 w00t!) you're likely to find yourself wasting a lot of time trying to come up with an error passing routine, I haven't found a real downside to just calling the display functions directly in case of error.

      The biggest benefit of this method is pure speed, you can develop small bits of functionality quickly within the framework, you can string them together arbitrarily for various combo pages (assuming you've been careful with your template namespace) and late additions can almost always be handled gracefully with a minimum of effort.

      Phi.

  • why doesn't php come with a code cache support? (Score:3, Insightful)

    by Kunta Kinte ( 323399 ) on Tuesday December 17, 2002 @02:30PM (#4908830) Journal

    I know there are accelerators out there, but most people not know about or use them. Plus I really can't see the harm in including a accelerator in the default engine. Does anyone know why it is not included? There are open source accelerators that can be distributed with PHP.

    Many scripting engines eg. Cold fusion, JSP, compile code only the very first time the code is executed since the module was started, then only check to see if the code was changed on disk before executing the already-in-memory code.
  • I'm too lazy to click any of the book links, and I'm sure many people here have the same question anyway, so I'll post: does the book show variables the old way (just ask for $whatever and it pulls the value out of the air from POST, GET, etc.) or the new (4.2+) way where you need to say $_GET['whatever'] or $_POST['whatever']?

  • PHP is good but TAL is the next generation of SSI (Score:4, Informative)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Tuesday December 17, 2002 @03:12PM (#4909180)
    One thing that stirkes about PHP is it's position in the market. It simply ownz all other SSI technologies out there. From ASP over JSP to Cold Fusion, PHP is one of the outstanding successes of OSS.
    Yet all these SSI technologies have in common that they still don't manage to really split Design from content. I was all in for PHP as my way of doing SSI stuff until I ran into TAL [zope.org]. It's the second (next to DTML) SSI Language that comes with Zope and has been reimplemented in Perl (PETAL). The essential difference to other SSI solutions like the #1 PHP is that all SSI-relevant tags only come as parameters to standard HTML tags and thus absolutly don't interfere with WYSIWYG HTML tools or other stuff that belongs to markup. You even can get good editors to switch of the non-html tal parameters to do your markup uninterfered. Once on the server content of tal-parametered markup (tal-speak: "mockup") get's replaced with the dynamic content. The point is: Either way you have documents that can be previewed in browsers, edited and formated without the source code for serverside dynamics being touched - or vice versa.
    A simple trick to establish true separation of content and code.
    • TAL looks interesting, but it does get tiring reading people say over and over things like this:

      "Yet all these SSI technologies have in common that they still don't manage to really split Design from content."

      Any web scripting language worth its salt has at least one templating system available for it. For PHP I prefer smarty [php.net].
  • 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.
    • 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.)
    • 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 most cases. File handling and regex come to mind immediately. 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.
    Again this is just my experience. I don't mean to offend any Perl coders because Perl is an excellent language. However, in certain cases it may behoove one to write the back end in PHP instead of Perl. Thank you, ET
    • I won't get into PHP-vs-Perl, as I think the two complement eachother nicely (if you realy know how to use mod_perl and PHP, you can do some amazing things with the Web which are not idealy suited to either one).

      However, you are incorrect on some 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.

      Since version 4 (over 10 years ago) Perl has had access to Sybase and Oracle. Newer additions (from the past 5 years or so) include MySQL, PostgreSQL, CSV flat-file DBs, DB2, *DBM, and an ODBC interface layer for just about any database.

      The DBI module provides one uniform interface [cpan.org] to all of these.

      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 most cases.

      This depends wildly on what you're doing. PHP is pretty slow when it comes to handling deep, and complex data-structures, but quite fast when it comes to handling simple data like strings. Perl maintains a balance between these two, and an elegant interface to C and C++ for applications which need to speed up critical sections of code.

      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.

      My Perl programs run on Windows, MacOS/X, VMS, all UNIXen, and many other platforms. Dunno what you've had trouble with, but I suggest you may have had trouble with Perl because you were not familiar with it.

      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.

      This is so wildly untrue, it's amazing! Perl has some of the most comprehensive graphics handling possible. From OpenGL to the GD module to PDL, Perl can do anything from complex scientific simulation graphics to simple 2 and 3-D charts and graphs to line-drawing. PDL [sourceforge.net] requires special note. It's a library for dealing with arbitrary binary data in a number of ways from performing vast arrays of numeric transformations (e.g. Fourier Transforms, and other matrix transformations) to rendering graphics to modifying image data. It's a god-send for the scientific community that previously had to deal with proprietary systems that were of dubious value given that they could not be modified.

      There's even a comprehensive interface to The Gimp, which I wrote an article on for The Perl Journal.

      The Perl resource that you probably are not aware of (based on your comments) is the Comprehensive Perl Archive Network (CPAN). There is a module list [cpan.org] that gives you a nice index of everything that Perl can do that is not shipped with the binaries. Perl also provides a CPAN module that can be used to automatically download, compile and install anything from CPAN.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close