Follow Slashdot blog updates by subscribing to our blog RSS feed

 


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

Web Database Applications with PHP & MySQL 275

Posted by michael from the many-little-cubbyholes dept.
Brian Donovan contributes this review of Web Database Applications with PHP & MySQL, the most recent of several books geared toward helping people use the common Linux, Apache, MySQL and PHP combination to produce database-backed websites. Read on for the review.
Web Database Applications with PHP & MySQL
author Hugh E. Williams and David Lane
pages 563
publisher O'Reilly
rating 9
reviewer Brian Donovan
ISBN 0596000413
summary A comprehensive, tutorial-style roadmap for building data-driven web applications with PHP and MySQL.

PHP's speed of execution, gentle learning curve, and ease of development have contributed to its popularity, especially when teamed with MySQL, as a tool for building dynamic sites. Williams and Lane have written a thorough step-by-step guide to building web database applications with PHP and MySQL.

The Meat of the Book

Part I (Chpts 1-3) of Web Database Applications with PHP & MySQL (Web DB Apps) introduces the "Hugh and Dave's Online Wines" case study that's used to highlight the points made throughout the text and treats readers to the fundamentals of PHP, MySQL, and SQL - appropriate since the book assumes only some prior programming experience (not necessarily in PHP) and a general familiarity with HTML.

Chapters 4-9 (Part II) deal with the aspects of web application logic common to practically all data-driven sites : querying and writing to databases, maintaining state, and security. Chapter 4, "Querying Web Databases", includes a good explanation (Ex. 4-1) of the mechanics of connecting to and querying a MySQL db via PHP - numbered blocks of the example script correspond to sections in the accompanying text detailing what's happening at each point in the process (connect, query, retrieve results, process results, and close connection- unless you're using persistent db connections).

Chapter 5, "User-Driven Querying", explains how to pass data to PHP scripts using HTTP GET and POST. Although readers are initially shown parameters and parameter values being passed directly (as they are when register_globals is turned on in php.ini), the authors later explain why the same param:value pairs should instead be accessed through the global associative arrays $HTTP_GET_VARS and $HTTP_POST_VARS (the book was completed before the switch to $_GET and $_POST respectively with PHP 4.2.0) for security reasons. What the authors refer to as "combined scripts" (where the same script performs different functions depending on which, if any, variables in the GET or POST arrays, have been set, for example) are introduced and the reader is walked through the oft-used "next and previous links for query results" scenario.

In Chapter 6, "Writing to Web Databases", in addition to inserts, updates, and deletes, the authors explain one solution to the reload problem - i.e. where reloading a results page after some operation that alters the contents of the database has been performed (or even accessing a bookmarked url if HTTP GET was used to initiate the action) can potentially result in the operation being silently repeated or, if HTTP POST was used, the user being confronted with a big ugly "would you like to repost the data?" dialog. Locking (mostly how to make the best use of table-level locking) is also discussed in all of its glory. Chapter 7 deals with the validation of user input. The authors recommend and give an example implementation of dual server and client side validation (with JavaScript). Chapter 8 covers sessions (with and without cookies).

The chapter on security (Chapter 9, "Authentication and Security") mostly concerns user authentication. HTTP Authentication, managed HTTP Authentication (using PHP to validate encoded credentials from the HTTP Authorized header field), and handling your own authentication are considered, along with the security concerns inherent in stateful web apps - i.e., third party sites maliciously tricking browsers into coughing up cookies with login or session information for your site, session hijacking by feeding random session ids to the scripts until one corresponds to an existing session, etc. SSL is explained briefly.

The third and final section of Web DB Apps (Chpts 10-13) consists of a detailed examination of the guts of the wine store case study. Readers who find the commingling of application logic and html in the snippets of the wine store application discussed in the book distasteful will be gratified to know that, since publication, the authors have released a modified version of the "Hugh and Dave's Online Wines" code that uses the Xtemplate class (http://sourceforge.net/projects/xtpl/) to separate code from markup. Both versions are available in their entirety for download from the book website.

The five appendices, in turn, cover the installation and configuration of PHP, MySQL, and Apache on a Linux system, the architecture and workings of the Internet and Web, designing relational databases using entity-relationship modeling, how to define your own session handler prototypes and store session data in a database instead of files (the default), and provide an annotated list of PHP and MySQL resources (books, web sites, etc.).

The Good and the Bad

While it's clear that Web Database Applications with PHP & MySQL was written with the goal in mind of providing novice coders with a solid foundation for continued growth (or filling the niche of "handy reference" on the shelf of intermediate/advanced developers), the book manages to be comprehensive without patronizing the reader. I admit that I wouldn't have felt cheated if the authors had skipped the obligatory coverage of the history of the Internet, TCP/IP, and HTTP (Appendix B) in favor of, for instance, a discussion of web caching with an eye towards building cache-friendly apps, an important subject that all too gets short shrift from authors of web dev books. Also, some readers may be disappointed to find that the chapter on security doesn't relate to battening down your site against script kiddies and exploits, but that's really the sort of information that you should be getting from sites like PHP Advisory and Securiteam anyway.

For seasoned developers, this could be the book that you wish you'd had when you started out building web database apps and data-driven sites. Keeping a copy around for reference, especially if you frequently jump back and forth between projects in different languages/environments, also might be helpful - for those occasions when you need of a quick refresher in PHP/MySQL dev. Moreover, if you find yourself in the position of having to mentor junior developers (or helping non-coder friends) tasked with building or maintaining PHP/MySQL-based sites or apps, then lending them your copy or recommending that they buy their own could save you quite a bit of time and frustration.

Table of Contents
  • Preface
  • Part I
    • Chapter 1. Database Applications and the Web
    • Chapter 2. PHP
    • Chapter 3. MySQL and SQL
  • Part II
    • Chapter 4. Querying Web Databases
    • Chapter 5. User-Driven Querying
    • Chapter 6. Writing to Web Databases
    • Chapter 7. Validation on the Server and Client
    • Chapter 8. Sessions
    • Chapter 9. Authentication and Security
  • Part III
    • Chapter 10. Winestore Customer Management
    • Chapter 11. The Winestore Shopping Cart
    • Chapter 12. Ordering and Shipping at the Winestore
    • Chapter 13. Related Topics
  • Appendix A. Installation Guide
  • Appendix B. Internet and Web Protocols
  • Appendix C. Modeling and Designing Relational Databases
  • Appendix D. Managing Sessions in the Database Tier
  • Appendix E. Resources
  • Index
You can purchase Web Database Applications with PHP & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.
This discussion has been archived. No new comments can be posted.

Web Database Applications with PHP & MySQL More

Web Database Applications with PHP & MySQL

Comments Filter:

  • don't need a book (Score:2, Interesting)

    by matt4077 ( 581118 )
    the online documentation at php.net and mysql.com is excellent, so beginner books are unneccessary.
    • I disagree, lots of people who are beginners would not know where to begin when trying to use PHP or MySQL. The documentation is great if you already have a basic understanding of what is going on, otherwise it is like Latin to y ou. Examples of what can be done lets you see why certain things are set up the way they are for a given language.
    • I agree. It took me about an hour of looking over the PHP docs to get basic syntax down. Later that day I was writing a complex backend system for my website. PHP docs are extremely good. The function reference is so useful I wonder how I would get along without it.

      Thumbs up for the people working on the PHP docs. They have made my life so much easier. I don't see why anyone would ever need a book for PHP.
  • LAMP systems (Linux, Apache, MySQL, PHP, for the newbies...) work really well and are easy to implement, especially if you know a little C,C++ and basic HTML. Looks like I might have to buy this book, any reference on this helps me...

    • Re:LAMP systems (Score:2, Interesting)

      by LetterJ ( 3524 )
      And WAMP (Windows, Apache, MySQL and PHP) is a lot more popular than most Linux users will admit. It's a great solution for small intranets. With the improvements in Apache 2 to make it more stable on Windows, it's works well when OS isn't a variable in the equation, but a constant.

  • I've said it before (Score:5, Informative)

    by wbav ( 223901 ) <Guardian.Bob+Slashdot@gmail.com> on Thursday June 13, 2002 @12:36PM (#3695181) Homepage Journal
    And I'll say it again. The best way to learn php is through the php website. [php.net] Go through all the documentation. You will learn more about what actually works and what doesn't than what a book can tell you. A book is always about a version behind PHP, and so learn it through the website.

    That's how I learned php 3 years ago, and well, I'm better with php than most.

    • Real Programmers Learn By Doing (Score:5, Insightful)

      by kzinti ( 9651 ) on Thursday June 13, 2002 @12:52PM (#3695312) Homepage Journal
      And I'll say it again. The best way to learn php is through the php website.

      I've said it before and I'll say it again: the best way to learn a language is by using it. Sit down at a computer with the manuals and start slinging code. You can't really learn a language by reading a book or going to a class. Real programmers learn by doing.

      If you want to supplement your programming with a book or tutorial, fine, but keep your fingers on the keyboard. If you want to run sample programs, fine, but experiment and play with them. Change them, tweak them, go off on your own tangents. Better yet: throw out the tutorial as soon as you can write "hello world" and try to write some program of your own design. Keep the language and library references handy, because you'll need to refer to them often, but let your imagination and curiousity be your guide. Explore. Play. Learn. Real programmers learn by doing.

      What I tell you three times is true.

      --Jim

      • Re:Real Programmers Learn By Doing (Score:5, Insightful)

        by mooman ( 9434 ) on Thursday June 13, 2002 @01:21PM (#3695540) Homepage

        Better yet: throw out the tutorial as soon as you can write "hello world" and try to write some program of your own design.


        This strategy works fine if you never want to be any better than a good programmer (at least in that particular language). Learning by doing is great for getting started but leaves you a far cry from being someone that I'd want to hire.

        As someone who has been through close to a dozen different languages, I've come to realize that the syntax is one of the easier things to pick up when learning a new language. What you need guidance on is about best practices in your new language.

        It's the old "when all you have is a hammer, everything looks like a nail" dilemma. Just because the using lists is a convenient data structure in, say, ColdFusion, doesn't mean it should be what you reach for first in "language X". This is especially true when maker bigger leaps from compiled to scripted languages (what? Verbose comments slows things down??) and procedural to object-oriented languages. Some of the (sorry, I gotta say it) paradigm shifts are key to writing optimized code in the new language. And you'll never grasp those through trial and error.

        So while I'll agree on the point that you have to have some hands-on to master a language, I'll strenuously object to the idea that hands-on can replace a good book (or other training source).

        • I agree wholeheartedly that it is important to learn the best practices of any given language. Syntax is easy to learn, but knowing the syntax to a programming language doesn't make you a good programmer any more than being able to write and spell makes you Shakespeare.

          That being said, the PHP manuals are an excellent piece of work. It is my opinion that they are largely responsible for the popularity of PHP. I have used web development systems that I feel are superior to PHP, but I have yet to see anything that is both as easy to use as PHP and as well documented. Between the PHP manual, the PHP mailing lists, and the vast wealth of freely available example PHP code, I just don't see the added value of a book. The manual is more than enough to teach you the syntax, the tutorial will get you started on the correct path, and lurking on the mailing list is as likely as anything to teach you to use PHP properly. If you really get stuck, chances are good that you can examine a working example from some other production quality product.

        • Judging by your home page (the counter doesn't even work) I don't think I'd want you to hire me.
        • "This is especially true when maker bigger leaps from compiled to scripted languages (what? Verbose comments slows things down??)"

          Not sure which scripting language you're referring to here. Even Javascript is now compiled and cached by browsers, so the pre-compiled version is used upon reloads (you can test this by running a benchmark script - the first run will take fractionally longer than all subsequent runs). I'm guessing perl doesn't fair any worse for having comments here and there.

          A few years ago you would have been right though...
        • Learning by doing is great for getting started but leaves you a far cry from being someone that I'd want to hire.

          As someone who has been through close to a dozen different languages, I've come to realize that the syntax is one of the easier things to pick up when learning a new language. What you need guidance on is about best practices in your new language.

          True.... but the nice thing about the PHP docs is that they have this stuff in it. The user comments in the documentation are frequently filled with snippets of code, and the docs themselves often have some. Best practices? There might be some out there I don't know about... but I like how user input and the maintainers seem to keep good practices a part of the PHP docs.

      • The best way to learn is to have someone dump a PHP system on you before they leave. You learn quickly when people start hauling out promises that were never delivered or scream about devastating problems they ignored a month ago.
      • (* [The best way to learn php is through the php website.] I've said it before and I'll say it again: the best way to learn a language is by using it. *)

        Stop telling people how to learn! Every head is different.

        I use a variety of approaches to learn. Websites are great for reference, but harder on the eyes than dead, pressed trees, and less portable IMO.

        It is sometimes hard to learn by doing alone because you may be doing something that works, but doing it the hard way without knowing that there is a better way.

        One a side note, one thing that bothers me about PHP is the lack of regional variables (sometimes called "globals" in web languages) without funky qualifiers. If I want to reference something often, I don't want to have to keep qualifying it. Qualifying also causes Law-of-Demeter-like re-work, or declaration rework, if you factor a local var to be regional.

        It is true that the PHP approach better "documents" a routine's interface to its surroundings, but sometimes a routine is dedicated to a particular task and I don't want to generitize it. Let it sit where it sits.

    • Re:I've said it before (Score:4, Insightful)

      by dimer0 ( 461593 ) on Thursday June 13, 2002 @01:09PM (#3695455)
      That's like saying that reading the dictionary is the best way to learn to speak English.

      You need something that puts pieces together, puts things in perspective, gives you a 10,000 mile high view and drills down into certain aspects of what it's trying to cover. .

      Just being devil's advocate. I learn from source code. After that, I hit websites that dive deep into the subjects (like the main php site), and finally I'll take a college course (community college, mostly) on the subject just to get it on paper that I know it.

  • Amazing... (Score:3, Funny)

    by PepsiProgrammer ( 545828 ) on Thursday June 13, 2002 @12:38PM (#3695197)
    I was able to download this book off kazaa in PDF form 3 days ago
  • there was better PostgreSQL support out there. While MySQL is *ok*, PostgrsSQL beats the tar out of it. It supports good old standard SQL syntax, while I have to go look up functions in MySQL. Of course, everything supports MySQL, but it's tough to find apps that support PGSQL. Regardless, my current development platform of choice is JAVA/J2EE + PostgreSQL. That's what I coded Squabble [squabble.org] in. I just wish there was more Open Source stuff out there for Java related stuff...
  • O'Reilly is like the Pepperidge Farm of computer books.
    "If it's an O'Reilly, it's got to be good."

  • I recently completed an elective course that was taught around the book "PHP and MySQL Web Development" by Luke Welling and Laura Thomson. I suggest giving this book a good look. ISBN : 0672317842

    • MySQL/PHP4 Database Applications [amazon.co.uk], by Jay Greenspan and Brad Bulger, Hungry Minds, ISBN 0764535374 .

      Welling and Thomson's book is a good reference for those who want to get to grips with practical projects straight off the bat. It includes webmail, shopping cart, session control, and web-forum/weblog applications as a matter of course, and begins with a sturdy look at PHP first, moving to MySQL once the basics are covered.

      Greenspan and Bulger's text is perhaps more traditionally concerned with constructing databases and the programming that surrounds them. Both books cover the material equally well, though I found some nuisances in the first book.

    • I second the recommendation for :

      PHP and MySQL Web Development
  • I've been entrenched with JSP heavily for the last couple of years, so I haven't familiarised myself with PHP yet. I needed a book that would show me a larger picture than I got in a web developer's job, and showed me how to put it together with more modern techniques.
    This book is a perfect example of why I choose O'Reilly whenever in doubt. Chapter 1 is an overview of how web applications are put together. Chapter 2 goes through all the basic PHP syntax (stuff that would take other books several fluffy dry chapters to process). Chapter 3 gets you through all the mySQL and sql basics so you feel comfortable with that, too.
    There's no 4 page tutotial entitled: "Using a text editor: Wordpad" There's also no kitch "Employee Database" example cop-out. Instead, Hugh and Dave give a realistic and usable storefront application. This book alone is probably enough for the independent web developer to get a functional site up for her/himself or a client.
  • You dont really need a book, but I bought one back when I first started php/mysql it was really helpful. Link Here. [amazon.com]
    • i got that one along with "core PHP programming" I had only done some vb programming before and ASP alsu using vbscript, so it was a good intro to PHP/MySQL. "Core" is a decent reference, but i find myself hitting the website or oriely's "MySQL&mSQL" as a reference more often.
  • Since there was a review about CGI and Perl there must me some PHP review today to be fair.

    You all are all wet use sh for all your web CGI / programing / culinary needs. It parses, dices, and slices.

  • Web Application Database security links (Score:1, Informative)

    by Anonymous Coward
    www.cgisecurity.com [cgisecurity.com]
    www.owasp.org [owasp.org]
    www.sqlsecurity.com [sqlsecurity.com]

  • Umm... why not just read the docs? (Score:5, Informative)

    by Hollinger ( 16202 ) <michaelNO@SPAMhollinger.net> on Thursday June 13, 2002 @12:54PM (#3695325) Homepage Journal
    I learned all I ever needed to know about PHP from the PHP Manual [php.net]. MySQL also includes a somewhat monolithic html file that provides a quick reference, as long as you know SQL.

    A useful little tidbit: If you want a quick way to look up information in the PHP Manual, go to http://www.php.net/whatever-you-re-looking-for. For example, http://www.php.net/mysql [php.net] will take you straight to the reference pages for MySQL.

  • But MySQL doesn't do UTF-8... (Score:4, Interesting)

    by andersen ( 10283 ) on Thursday June 13, 2002 @01:03PM (#3695400) Homepage
    Too bad MySQL doesn't do UTF-8. That is a major problem for me in adopting it. Anybody know if that is getting fixed sometime soon?

  • aminamals (Score:5, Funny)

    by X_Caffeine ( 451624 ) on Thursday June 13, 2002 @01:03PM (#3695411)
    Chapter this, section that, blah blah, how about the important stuff: What kind of animal is on the cover?

  • Book has a missleading title (Score:5, Informative)

    by Neil Watson ( 60859 ) on Thursday June 13, 2002 @01:06PM (#3695428) Homepage
    While I like O'Reilly and have many of their books, this one was disappointing. It should have been called "Building E-Commerce Applications with PHP and MySQL" as most of the book focuses on building an online shopping site.


    If that's what you want then it's a good book. If you just want a general overview of the different sites you can design using the php/mysql combination then I think you'll be disappointed. I was.

    • I'm writing on web-based lab equipment reservation tool with PHP & MySQL and this was one of my main references. It was just fine. Just because they don't hand you your app on a platter doesn't mean it's only good for people who want to build E-Commerce sites.
    • I checked out WROX's Professional PHP4. It had everything I wanted to do... create an email and news clients. It deals how to make an FTP client. It talks about use with MySQL and PostgreSQL. I found it rather helpful (along with php.net's documentation and user notes). Bah, here's an overview [wrox.com].
    • Correct me if I'm wrong, but isn't an e-commerce application usually a "web database application"? Have you managed to make an e-commerce site that doesn't use a database?

      The techniques learned from making an e-commerce site can be applied to just about any database-based site.
    • It incredible, coudn't they just make it more fun to learns something? People doesn't want to learn everything in a straight line nor accomplish a "grand proyect".

      Teaching with separate, well thought out examples (small or medium size each) is much better. The "grandmaster project" also needs to force usage of a lot of functionality that hurts the teaching and the intelect as well.

  • Transactions? (Score:4, Insightful)

    by rochlin ( 248444 ) on Thursday June 13, 2002 @01:07PM (#3695433) Homepage
    Does this book include anything on transaction processing?

    Since transactions are a relatively new part of MySQL (and so, presumably new to PHP's interface to MySQL), a good part of the value of a new book on the subject of PHP/MySQL website building would relate to that new feature (which would also help with the double-entry problems mentioned in the review).

    So, does the book cover this topic or not? I can't tell from this review.

  • I *hate* DB programming in PHP! (Score:3, Informative)

    by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Thursday June 13, 2002 @01:07PM (#3695437) Homepage Journal
    In my opinion, PHP just isn't worth the hassle if you're going to be doing a lot of database work. Why? Because no two database interfaces in PHP have the same syntax or featureset! My company was switching a site from InterBase to PostgreSQL and we had to completely re-write the backend routines from scratch:

    • The InterBase DBI requires you to fetch rows sequentially: while($row = $result->fetch_row){ print "
      $row->firstname\n";}
    • The PostgreSQL DBI requires you to fetch rows by index number: $maxNum = $result->rows; for($i = 0; $i < $maxNum; $i++) {$row = $result->fetch_row($i); print "
      $row->firstname\n";}
    • The InterBase DBI allows you to use case-insensitive hash keys: $row->FOO or $row->foo
    • The PostgreSQL DBI requires that the hash key case be identical to the database field name: $row->tableOneISStRaNgeLYCapPED


    If you're starting with a new project and know for a fact, beyond the shadow of a doubt, that you'll never be changing database backends, then PHP isn't too bad. If there's an possibility (however remote) that you'll ever move from, say, MySQL to PostgreSQL, then DO YOUR WORK IN PERL! I can't tell you how much I missed Perl's DBI::DBD modules - I could've completed the transition in an hour or two instead of weeks. I know that there are efforts to provide similar functionality in PHP, but it just isn't to Perl's level yet.

    • Actually, I just migrated a database-driven website from MySQL to Oracle without a hitch, all using php.

      A database abstraction layer was used which made all the difference. I used dal [sourceforge.net], which is a nice object-oriented layer that only involves changing a single line of code to change different databases.

      Personally, it sounds to me like your company's problem was bad design (not allowing for expansion) rather than php.

      • Re:I *hate* DB programming in PHP! (Score:4, Insightful)

        by pi_rules ( 123171 ) on Thursday June 13, 2002 @03:58PM (#3696884)
        A database abstraction layer was used which made all the difference. I used dal [sourceforge.net], which is a nice object-oriented layer that only involves changing a single line of code to change different databases.

        Personally, it sounds to me like your company's problem was bad design (not allowing for expansion) rather than php.

        Thank you! I am absolutely sick of developers blaming PHP for being bad at switching databases because they didn't built their app properly. PHP lets you get right down to the raw nitty gritty DB specific stuff -- which is nice, but you really shouldn't ever be using those UNLESS you are writing a wrapper, or really don't care about database independence. I really wish the php.net official manuals would warn new developers of this.

        The very fact that this book targets PHP and MySQL sort of ticks me off too -- why not PHP and DB wrappers? Why MySQL of all things too? It's horrid (sorry) ... for large scale sites IMHO.
    • Not sure if these are the efforts you're referring to but they're available for some of the more widely used backends (MySQL, Postgres, DB2, ODBC).

      Yes, there are arguments to be made against DB abstraction layers if you're using very specific features on one platform that might not be available on another (e.g. Postgres' foreign keys and subselects vs. Mysql's lack of them (er, last time I used MySQL anyway))

      But if you're doing fairly run of the mill SQL stuff, check out the PEAR DB class [php.net] or ADOdb [weblogs.com]. Either one implements a standard set of methods for interacting with databases regardless of the backend.
    • You can easily write a class (or find many online) to handle DB abstraction like Perl's DBI. It's just not included like the DBI is.

      But I'm surprised you would think a DBI layer would absolve you from lots of work in changing DB backends?

      Changing RDBMs' isn't something you do every day, nor should it be taken lightly. Expecting to not have to modify code (which is a reason I hear all the time for DB layers) is false for several reasons:

      1) For all but the simplest SELECT statements most RDBMs' SQL implementation differs enough that you'd have to re-write your complex queries. As shown in your example of transactions, Oracle uses sequences to create auto_incrementing integers. MySQL uses a column type of 'auto_increment' and requires you to explicitly insert NULL. Sybase and MS SQL use IDENTITY columns but requires that you leave the identity column OUT OF the SQL statement.

      2) You should check EVERY SINGLE QUERY to make sure it performs well in your new environment. Oracle may use an index (or two) in a situation when MySQL will table-scan, causing your query to take 200x as long to complete. Switching your backend DB should not be a 'fire and forget' situation!

      3) Most Enterprise RDBMs' include the concept of Stored Procedures. These, actually, are a GREAT way to achieve DB independence (to some degree) in your application. For example, say you have some code like this: *_query( "get_user_info $userid" ); As long as my stored procedure is named the same, takes the same parameters, and behaves in the same manner I don't have to change that line at all! I can write the SQL in Oracle's PL/SQL, Sybase/MS SQL's T-SQL, etc. and the application logic does not have to change.

      However, DB abstraction layers are nice since you can include error checking and array-fetching as you showed very easily. I'd say the greatest advantage to using an abstraction layer are the class functions you create for it. I use DB layers on all my programs for those reasons, NOT for DB independance.
    • I *hate* DB programming in PHP!

      Me too. I uninstalled PHP a while back. The database-specific functions exemplify what is both good and bad about PHP.

      BAD: Nothing is really object-oriented. Code is completely un-portable. PHP code is useless in other environments like binary or batch development (unlike Java, VB, C++, etc...and no whining about how someone's made a PHP->binary compiler...it ain't the same.)

      GOOD: Nothing is really object oriented. Each of the modules (one hopes) is stripped down and about as fast as possible. In the case of database access, you're opening native connections directly the database instead of wading through ADO/ODBC/JDBC or any of the other things that abstracts your access. Another example, mailing functions...works DAMN well, and is as simple as can be (ASP, Java obviously can do it...but) from both a programming and functional standpoint.

      So I suppose I'd use PHP if I had a moderately small site that I wanted to use for a fairly specific purpose, one that once I'd built I wouldn't have the time to port to something else anyway. However, if the site was something that would be maintained by a large number of people, over a long period of time, and have to integrate with a variety of databases and such, I sadly wouldn't consider PHP for a second.

      • Code is completely un-portable.

        The code is interpreted so how can it not be portable?

        PHP code is useless in other environments like binary or batch development (unlike Java, VB, C++, etc...and no whining about how someone's made a PHP->binary compiler...it ain't the same.)

        Again can you explain more clearly? I use PHP for batch processing without any problem. You can also use PHP to write command line or desktop apps, though it's obviously not suited to developing large desktop apps as it wasn't designed for that.

        So I suppose I'd use PHP if I had a moderately small site that I wanted to use for a fairly specific purpose

        This is what PHP is primarily designed for, imho. I think you needed to read the instructions on the side of the tin before purchasing...

        Phillip.

  • phpclasses.org (Score:5, Informative)

    by djaxl ( 543958 ) <[moc.puorgavaleulb] [ta] [ikswolsewa]> on Thursday June 13, 2002 @01:08PM (#3695440)
    People keep mentioning php.net [php.net]. I have to put my vote in for phpclasses.org [phpclasses.org]. No friendly tutorials here, just the code you need. Functionality ranges from basic stuff like turning recordsets into an HTML table, to more advanced things like data caching.

  • Big problem with most PHP Books (Score:5, Insightful)

    by saberworks ( 267163 ) on Thursday June 13, 2002 @01:12PM (#3695465)
    The biggest problem with all the PHP books out there is that they don't talk about software design or good coding practice. They show you some syntax and some functions and leave you on your way. Most do not discuss things like database abstraction, HTML templates, or even object-oriented programming. Without thought to design considerations such as these, most PHP programs end up being hacks full of HTML code mixed with PHP code mixed with native database calls. This might be well and good for a small script on a personal site, but when you're talking about a commercial-grade application, you really need to have all this separate. You can't expect someone to learn PHP just to change the design of their web site which uses your PHP scripts.
    • The biggest problem with all the PHP books out there is that they don't talk about software design or good coding practice.

      Agreed. I recently had to jump into the PHP pool, so went search for books on exactly this. I've been doing web development with perl for something like five years, know a couple other languages fairly well, and dabble in another few. So syntax and learning the language weren't an issue - I just wanted to know what the best way to use this tool was.

      After spending the better part of a day researching and perusing PHP books I settled on that New Riders title, Advanced Web Development with PHP or something (don't have the book handy, I probably got the title wrong). It was written by a couple of core developers, had some stuff on the back on developing PHP itself, and a sample application or two.

      Unfortunately, the book really lacked focus. No best practices were extrapolated from the example code, and only the vaguest nods toward larger architectural issues were given. It wasn't entirely useless, and it did smooth out one or two learning bumps, but it wasn't worth the cover price.

      This seems to be a common unfilled niche, at least in web-related development books - titles aimed at the experienced developer who wants to get up to speed on a new tool fast, with a minimum of "this is what a TCP/IP stack is" or "here's how you use a for loop". I don't know, maybe it's because it's harder to write a good book dealing with larger, real word issues, than it is to just reprint the function reference.

  • ADO for PHP (Score:4, Informative)

    by Kamel Jockey ( 409856 ) on Thursday June 13, 2002 @01:16PM (#3695503) Homepage

    As someone who does database coding for PHP nearly everyday, I must say the ADO interface that can be found here [weblogs.com] has been a godsend. It makes it so easy to create database independent code with minimal overhead. Of course, this package is open source :)

  • Rasmus' is the best PHP book I've ever read, (Score:3, Informative)

    by TheTomcat ( 53158 ) on Thursday June 13, 2002 @01:24PM (#3695564) Homepage
    I just finished reading Programming PHP [oreilly.com], Rasmus Lerdorf's latest co-authored book.

    It's by far the most concise, useful, and down-and-dirty books I've ever read on PHP. Even the usually-useless PHP function reference in this books is a step above the norm.

    The book talks about important things like PDF creation, the GD library, and how to extend PHP. Setting up and connecting to a DB is kept to a minimum. Kudos to the man.

    S
  • I am curious, what does PHP offer that Perl does not? I'm not trying to troll, or start a flame war, I just honestly don't see what PHP gives me.

    One thing I see people say is that it can be imbedded into your html, but you can do that with Apache::ASP, and a bunch of others, I wrote one myself for my current job.

    Plus, with mod_perl, you can write your own handlers in Perl, which is really great, not sure if you can do that with PHP...

    But the number one advantage with Perl, IMHO, is the CPAN.

    I just don't see what PHP offers that Perl doesn't already do better.

    Now, please folks, I'm interested in hearing what PHP actually offers, I'm not looking for "Perl looks like line noise" or "PHP is Perl for girlies" type comments.

    • For me, the main advantage of PHP is precisely that it has a subset of the features Perl offers. For writing web applications, it is often very handy to have a simpler syntax and fewer builtins - it makes it easier to manage code, removes the temptation to obfuscate, and makes it a lot easier to teach others how to code the web app ( a consideration for me, working with lots of student assistants). For most web applications, you need to basically do just the following:
      • Keep track of users and sessions
      • Print the results of database queries
      • Update a database
      • Use conditional logic to select what kind of HTML to display

      For that stuff, Perl is overfeatured. Using PHP is simpler, you can embed it in your HTML with the syntax, and it makes for faster development.
      For serious text processing, you can always exec perl programs, or pipe output/input to Perl daemons.

      All that being said, mod_perl is wonderful, too, especially if you know the language already, or have a really complex web app.

      Right tool, right job, etc.
    • i tend to agree with you. i stared out using php and gave it up for all the stuff in cpan. i commented on it recently here:

      comment [slashdot.org]

      if someone posts a link to pear, keep in mind it's nowhere near as polished and feature rich as cpan.
    • One argument that is often brought up (in my experience) for not starting a project in Perl is that there is no rigid style guide. A C programmer can write in in C syntax, a shell programmer in shell syntax, etc. It's too flexible for its own good when it ends up in the maintenance phase. After seeing many peers suffering fixing unwieldy Perl scripts I even avoided going on any Perl training course. PHP is much simpler and has a reasonably rigid syntax, which makes it far easier to cast your eyes over and absorb strange code.

      The PHP vs Perl comparison reminds me of the C vs C++ one. The former of each is simple, almost a complete subset of the latter, and is appreciated by many as being easy to maintain. The latter of each is touted as more powerful, better OO, wider range of classes, but turn out more complex code having a higher maintenance cost.

      Much like C and C++ co-exist today, PHP and Perl can also. For simple web apps, PHP is perfect. Those that know Perl can continue to use it, there is no great incentive to change. Then for sites that need massive scalability there is Java. If you know Perl, why not have a play with PHP? It's one more tool to add to your arsenal.

      Phillip.
    • I am curious, what does PHP offer that Perl does not? I'm not trying to troll, or start a flame war, I just honestly don't see what PHP gives me.

      I've been using perl for web development for some time, and just this spring started using PHP. I'd looked at it as an alternative in the PHP3 days, but the lack of database abstraction turned me off. The language has come a long way since then, but there are a number of things I find awkward about it. The reason I've mostly switched to PHP (for the moment) is because a) a couple of projects that had PHP/MySQL as a requirement came up, and b) by the time those were done, I had a large reusable code base that did pretty much what I'd been planning to do with perl only a few months ago. I've got much more experience with perl, though, so add the appropriate amount of salt.

      First, as far as I can tell, PHP doesn't give you any functionality that you don't get in Perl. I frequently find myself doing a lot more typing with PHP than Perl would require to do the same thing.

      Second, someone here mentioned that PHP has a more focussed feature set, and is therefore easier for web development. I tend to disagree. PHP is heavily weighted towards database access, HTML manipulation, session management, etc., but at the same time there are a whole lot of functions built into the core language that, frankly, I think are superfluous. Once or twice I've come across something that I thought would be really cool if Perl had it, but my overwhelming impression was: too much in the core language. Syntactically, PHP might look easier, but if you've already mastered Perl syntax, there's no gain here.

      Third, PHP is designed to be integrated into HTML. This can become largely a religious issue, but I think that's a Bad Idea, for a whole lot of reasons. I like the HTML::Template module in Perl a whole lot because it minimizes the amount of logic you can mix in with your HTML. The Xtemplate class mentioned in this article looks like it has a similar goal, but PHP as a language encourages the mixing of code and logic. It just doesn't sit right with me.

      Fourth, (and some might consider this a non-issue) is that I just don't like using a function call for a regex match. I like Perl's binding operators much better.

      Finally, the language is not as mature as Perl. Functions are renamed between point releases (from the array_key_exists() definition: "Note: This name of this function is key_exists() in PHP version 4.06") and major changes in the default configuration between point releases (form variables no longer auto-vivified as of PHP 4.20 (yes, I know the reasons, but I'm savvy enough to initialize my variables before use, thank you very much)). Functions are also frequently named in incosistent ways. Some use underscores in them, others interspersed caps, and functions that do similar things don't always have names constructed in a similar way (key_exists vs. all the other array_x functions isn't the best example, but I don't have any others at my fingertips. I've run into a few of them, though). This isn't confidence inspiring.

      The main argument that I've heard in favour of PHP over Perl is that the length of time it takes for someone new to web programming to learn to do the same things Perl as are built in to PHP (session handling, database access, etc) is shorter. I'm not sure that I agree - I've never found it difficult to pick up a new module. But as I said, I've been using Perl for a while.

      The only advantage I've personally found to using PHP so far has little to do with the language, and more the way it's deployed. I never know where a web site I develop is going to live. Unfortunately, the vast majority of hosts seem to toss on the default Perl install and call it a day. Not being able to count on, say, DBI, is a real bitch. I could say that the site requires mod_perl, DBI, the libnet bundle, etc., but a) that gets you a lot of blank stares (yes, from hosts), whereas with PHP, I know I'm getting a database, and it's probably MySQL, and various other goodies.

      Tangent: One of my big hopes for Perl 6 has nothing to do with the language, but with the way it's deployed. I'm really hoping that a small core language with SDKs (a web development SDK with DBI, libnet, and Mason. yum) will encourage sysadmins to put more stuff I need on their servers. Untill that happens (or we start co-locing all our sites), I'm probably going to be using PHP for the bulk of our development. It makes me sad that I'm using a tool that, while workable, I don't find as powerful as Perl, still has a lot of rough edges, and with a far inferior toolbox (no CPAN) simply because what I often need isn't widely installed.

      I've gone on enough, but I hope I've given you a bit of insight into my experiences with the two tools. PHP is servicable, but Perl really helps me. If you have control over hosting environment, stick with Perl. You'll get more mileage out of it.

  • embedded perl (Score:3, Informative)

    by SCHecklerX ( 229973 ) <greg@gksnetworks.com> on Thursday June 13, 2002 @03:31PM (#3696626) Homepage
    I prefer using embedded perl to PHP, plus you get all the goodness of mod_perl speed. You can also use any standard perl module in your web pages then. Check it out:

    http://perl.apache.org/embperl/ [apache.org]

  • "Gentle learning curve"? (Score:3, Interesting)

    by Tim Ward ( 514198 ) on Thursday June 13, 2002 @03:46PM (#3696774) Homepage
    Why oh why can't people get this right??

    A "steep learning curve" is one where you go up, and get to the top, quickly, ie the thing is easy to learn quickly.

    A "gentle learning curve" is one that you climb up slowly over a long time, ie the thing is a right pain to learn and takes ages.

    So why do people who appear to know English get these the wrong way round? Is it perhaps that they're not illiterate, they're just innumerate and haven't a clue what a graph is?
    • A "steep learning curve" is one where you go up, and get to the top, quickly, ie the thing is easy to learn quickly. [...] they're just innumerate and haven't a clue what a graph is?

      I knew even before I checked your homepage that you lived in Cambridge... where they don't have any hills. The trick to understanding the graph that you missed is that you need to stand the bit of paper on its edge. You are right about time going along the x-axis, but a steep climb is far more difficult to walk up (whether mentally or physically).

      A steep learning curve is hard too learn, but will get you there more quickly. And vice versa for a gentle learning curve.

      Phillip.
    • Because you're think speed and they're thinking effort. More probably, you're thinking like a mathemetician... a steeply rising curve is one that rises quickly. A genly rising curve takes forever.

      A steep curve has a steep slope. Sure, it rises quickly if you're just plotting height against some horizontal variation, but if you're climbing it, actual progress can be very slow inded. A gentle curve rises slowly, but is easy to move over, so actual progress can be quicker. This becomes very clear after you've done a bit of mountain hiking, and most of us on slashdot could use some time outside, so I urge everyone to try this.

      When I think steep learning curve, besides thinking of bushwhacking up Jacob's Ladder to get to Lone Peak (overlooking Salt Lake City, Heber, and Provo in Utah), I think of Finale (the music typesetting program). Holy cow, you have to fight to learn that thing.

  • Other option: openACS (Score:2, Insightful)

    by Cirkit ( 584149 )
    I'd like to recommend the excellent openACS [openacs.org] toolkit. Not PHP and not MySQL (ick), but a mighty fine, totally open source toolkit for building communities, e-commerce, etc. PostgreSQL rocks, or if you're feeling spendy, it also supports Oracle.

    The best thing about the openACS toolkit is that you can have a functional db-backed site up in no time. No need to re-invent the wheel. :)

  • Has anyone tried to write a generalized web application framework (or even server) that uses PHP? I appreciate the PHP database and session stuff, but sometimes it would seem if there was a framework that was a little bit beyond this, I could save some time.

    Yeah, I could write one myself (and in fact I am), but I'm thinking I can't be the only one thinking about this.

  • Now would be a good time to ask for beta testers of a new XML module for PHP [progressiv...ishing.com]. One thing that's been a big fault of nearly all PHP apps available is the storing of the configuration as a list of hard-coded variables (usually called config.php). This makes it difficult for the app to update its own config, and certainly reduces the chance of 3rd party config plug-ins.

    There are a couple of xml modules that are veneers onto standard XML libraries, and also a good PHP Class, but all are not that easy to use. I wanted an API that took under 10 mins to learn and be competant in. You can see it here [progressiv...ishing.com]. So simple it only took me a couple of minutes to write a XML-based guestbook [homeip.net]. Another example is here [homeip.net]. Install instructions are on the site, feel free to have a try and give any feedback.

    Phillip.
  • As it says on the link in the review, $_GET, $_POST & co. were implemented in PHP 4.1.0 and not 4.2.0. Just in case anyone wants to compile a history ;).

    As for the book... personally I wouldn't have found it useful (based on this review) at any stage of my PHP education. The online manual is simply too good. I really don't see what else is needed - good coding practice can be figured out with common sense - a mix and match from Perl, C, and (more and more these days, especially with Zend 2) Java.

    The function reference is superb - not to mention the user-contributed notes, which as often as not have the answer to your specific question. My Galeon is, not surprisingly, outfitted with a Smart Bookmark to the function reference. Beats a book any day.

Slashdot Top Deals

According to the latest official figures, 43% of all statistics are totally worthless.

Close