Web Database Applications with PHP & MySQL

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.

Comments

don't need a book

[matt4077]

the online documentation at php.net and mysql.com is excellent, so beginner books are unneccessary.

Re:don't need a book

[Pi Kapp 142]

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.

Re:don't need a book

[Richard_at_work]

That all depends on waht type of beginners they are. If they are previous coders who are moving to a new language, then the sites are enough, as thats exactly waht i did. i bought a couple of books, mainly WROX ones, and found the php ones to be shite.
For total beginners, then yes, maybe they will need a bit more to learn the proper structure and methods, but thats more of a true beginner thing.
Me, myself, i use these sorts of books, and articles on the internet jsut like them, to stop myself reinventing the wheel. I look at the stuff they do and then think of any projects im currently part of that will benifit from the methods and stuff.

Re:don't need a book

[earthpig]

i hole heartedly dissagree.

unless the have changed receintly, i 've found the online documentation for both php and mysql the most frustraing. as i beginner, i spent countless frustrationg hours getting nowhere with the online documentation.

almost all gpl free gnu open source documentaion about as helpful as continually hitting my self in the head with a hammer.

Re:don't need a book

[JebusIsLord]

I agree that the php.net documentation is actually pretty good, AS A REFERERNCE. I prefer to have a hard-copy text on-hand to explain how to do things step-by-step, and as a fairly novice coder I like to keep my O'Reilly Programming PHP on hand for walkthroughs and alternative methods, with php.net open in a browser window for quick function reference. Plus, I can go outside and lay in the sun with a textbook, like I am about to right now!

Re:don't need a book

[Antipop]

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.

Re:don't need a book

[vectorswept]

This is simply not the case. I have found very little software on any platform that has more or better documentation than the Free Software Foundation's software If you read Perldoc or use info to find out about Linux commands you will find it user friendly and informative.

I am not familiar with PHP's information but don't use the same brush for gnu's software.

Re:don't need a book

[drpatt]

Same here. Anyone who can learn this stuff just from the online docs is an experienced programmer or a Einstein clone. For the rest of us, we need more. And I suppose man pages are all you need to learn Linux, right? :)

Re:don't need a book

[neuroticia]

Not necessarily so. Documention is documention, and there are plenty of simple how-to's or tutorials and manuals online that are suitable for the beginner.

The primary benefit of a book is the ability to bring it anywhere and read it with minimal eyestrain. For example, I can bring my book into the bathroom and catch up on some concepts that I don't use day-to-day but that I'm interested in because they might make some task easier.. Or I could bring it to the dog run while I'm excercizing the fuzzy-beast. Both of these places are things that you most likely will not want to bring a computer, even a laptop.

Besides... When I'm a beginner in something I don't want a book. I want online tutorials, things I can copy/paste to quickly see how they work.. THEN when I'm sure that something is worth learning I'll buy the book, and it will sit on my shelf until I'm comfortable with the concepts and know what I'm looking for.

Linux, for example. If I knew that I wanted to do a "backup", chances are "backup" wouldn't be in the index and I'd have to putz around looking for something that would suit the bill. Online I can do a search for "Linux backup" and get an idea of what I need to know. From there I'd probably start researching cpio, afio, tar, backup media, incremental backups, etc.

I think books are positively worthless to the beginner. They only begin to become useful when the beginner becomes 'intermediate' or progresses to the point where they know enough about the subject to know what they're looking for in the index.

-Sara

Re:don't need a book

[php_freak_eternal]

I honestly tend to think otherwise. I have used the information from WROX PHP books to full effect in real world.I even tried the Hugh and Lane book,the peter black book and found them shitty.The best combination i found was the Professional PHP4 from WROX and the Essential Func Ref from New Riders.

LAMP systems

[NewbieSpaz]

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

[LetterJ]

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.

Re:LAMP systems

[vectorswept]

It probably is more popular than linux wonks would like to admit, but it is in fact less popular than windows people grok. I think you point right to the heart of the issue, it is platform agnostic which makes it valuable software.

Re:LAMP systems

[jjsjeff]

If I may throw my $0.02 into the mix...

Linux Magazine has a "LAMP Post" section in their magazine. It is usually well written and older months are available here.

Moreover, I read Linux Magazine cover to cover (multiple times usually) faithfully every month. There is information in there for everyone.

I've said it before

[wbav]

And I'll say it again. The best way to learn php is through the php website. 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.

Re:I've said it before

[dimer0]

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.

Re:I've said it before

[jrmann1999]

Nevermind those pesky "algorithm design and analysis" topics. Or the theories on how languages are derived(basically making you able to pickup any language in a few hours).

Don't get me wrong, I love just diving in and getting into coding. When I was pre-college I did that daily. Then when I actually learned how to plan what I was doing my code was 100x better. The only thing that diving in gets you is horrible style and structure.

Re:I've said it before

[kzinti]

Learning how to design software, and learning how to implement a design by programming in a language are two different (but related) things. Software design skills tend to apply across broad swaths of languages, though of course design skills change depending on the language: designing for an object-oriented language is and should be different than designing for a non-OO language. (Though an OO language can be reduced to a non-OO language if you don't use it well; who was it that said "A good programmer can write FORTRAN in any language"?)

"Diving in" doesn't necessarily lead to horrible style and structure. A good disciplined programmer can dive into a new language and find ways to transfer his good coding skills to programming well in the new language. Good style is largely orthogonal to specific languages - likewise if you're a sloppy C programmer you'll probably also be a sloppy perl, PHP, or Python programmer.

--Jim

Re:I've said it before

[neafevoc]

Definitely.

First I started out with Professional PHP4 from WROX (just to give me an idea). But they don't go through all the functions, therefore I headed over to php.net. The normaly documentation for the functions didn't do too much for me, but the user contributed notes did A LOT. (I was also new to MySQL, i wish mysql.com had as much documentation.)

And if php.net still couldn't answer my question, I finally sucked it up and asked on #php on OPN. They can be just as helpful... but normally I would get the RTFM and end up finding it again on php.net :)

Amazing...

[PepsiProgrammer]

I was able to download this book off kazaa in PDF form 3 days ago

Re:Amazing...

[Anonymous Coward]

You should've reviewed it for Slashdot.

I really wish...

[Clay Mitchell]

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 in. I just wish there was more Open Source stuff out there for Java related stuff...

Re:I really wish...

[axxackall]

there was better PostgreSQL support out there...

I just wish there was more Open Source stuff out there for Java related stuff...

Try Cocoon (if you love functional programming on XSL) or Struts (if you are poisoned by EJB) from Apache. Both work nice with PostgreSQL.

Or better try Zope and Python if you love OOP and hate Java-monster at the same time.

Re:I really wish...

[StevePark]

Well, if it's open-source Java/J2EE tools you're after, there's JBoss, Jetty, Tomcat, Struts, Ant, Resin and a soon-to-be-released open-source JDK from the Apache group. Personally, I love JBoss. It's very powerful, easy to use and is completely cross-platform (i.e. no native code).

Another O'Reilly Book

[baldass_newbie]

O'Reilly is like the Pepperidge Farm of computer books.
"If it's an O'Reilly, it's got to be good."

Re:Another O'Reilly Book

[$rtbl_this]

"If it's an O'Reilly, it's got to be good."

Sadly their Apache and MySQL (at least the first edition - I haven't seen the new one) books undermine this. I used to buy ORA books sight-unseen, comfortable in the knowledge that they'd be good. These days I've learned to check them out first and compare them to any Wrox or New Riders books on the same subject.

Another great book on the topic

[essdodson]

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

Re:Another great book on the topic

[intuition]

I second the recommendation for :

PHP and MySQL Web Development

Re:It's amazing how far this language has come

[LetterJ]

PHP didn't start out as a Perl script it was a series of little C programs.

I've read this one too....

[Grape Smuggler]

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.

Re:The Web is Dead

[LetterJ]

PHP has an experimental .NET extension and I'm sure several of the others if not all will have one soon if not already.

I appreciate your pedantry

[ObviousGuy]

But this history of PHP says that I'm right.

Re:I appreciate your pedantry

[LetterJ]

Then we may have a Bob Dylan-esque "shifting background" kind of thing going on. I based my comment off of a speech I heard Rasmus give. His "history of" focused on building the C programs at work for others to use.

Re:I appreciate your pedantry

[crimoid]

I would think that you are both correct.

initially as a simple set of Perl scripts.......As more functionality was required, Rasmus wrote a much larger C implementation

Well

[sheepab]

You dont really need a book, but I bought one back when I first started php/mysql it was really helpful. Link Here.

Re:Well

[GutBomb]

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.

It must a requisite

[theManInTheYellowHat]

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

[Anonymous Coward]

www.cgisecurity.com
www.owasp.org
www.sqlsecurity.com

Re:Using PHP and MySQL for a website...

[LetterJ]

Of course. Because we know that EVERY website gets 100s of simultaneous connections per second. As a matter of fact, all websites NEED 3-tier load balanced solution with an enterprise database in order to pull SELECT * FROM content WHERE id = $content_id out of that database 100 times per day.

Real Programmers Learn By Doing

[kzinti]

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

[wbav]

I never ment to understate how important it is to also try what you learn, but with relation to this article, a book is always a version behind, and never quite right. Where as the user contibutions on the php site can give you real insight to how the code works and how you might use it.

Re:Real Programmers Learn By Doing

[kzinti]

My comment wasn't meant as a criticism - in fact what you said about the website doco was right on the mark. I learned PHP myself by downloading the HTML manual and reading it while I played with the language.

But whenever I see someone say something like "The best way to learn programming language Z is to..." it kind of sets me off. Of all the programmers I've known, the best ones always want to get their hands on the compiler first thing when learning a new language. And that's my personal experience too: it's all find and dandy to read something in a book, but deep learning, the kind that sinks in and stays, doesn't begin until I actually use the language.

--Jim

Re:Real Programmers Learn By Doing

[mooman]

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

Re:Real Programmers Learn By Doing

[Jason Earl]

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.

Re:Real Programmers Learn By Doing

[Afrosheen]

Judging by your home page (the counter doesn't even work) I don't think I'd want you to hire me.

Re:Real Programmers Learn By Doing

[FyRE666]

"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...

Re:Real Programmers Learn By Doing

[kzinti]

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 never said hands-on would replace books or even training classes. In fact, I believe I said several times that the hands-on needed to be accompanied by reference or tutorial material. But I don't think that books and training are the critical factors in learning a new language; I think real hands-on experience is.

Furthermore, I absolutely do not equate experimenting with a language to "trial-and-error". Just the opposite: in playing around with a language, once you know the basic control structures and syntax, I expect you to learn the language's strengths and weaknesses: how good is its object model (say), or its data structures, its exceptions, etc., etc. I expect you to test it, to put it through its paces. True, you can read about these things in the language reference, but until you actually put them into play, you don't get that deep visceral feel for how well they actually work in practice. In particular, I like to take difficult problems that I encountered in the past in other languages, and see how well the new language is set up to deal with the same problem: does it deal with it better, or worse? What are the tradeoffs? Clearly now we're way past "hello world", but as I said: you want to implement some nontrivial program of your own design.

Nor do reject the idea of learning from reading, be it "best practices" or "don't do this". That kind of material definitely has its place in the equation, but I don't think it becomes effective until you're reasonably fluent in a language, and especially until you've had the chance to transfer your own skills from other languages. I think you have to draw on all that you have available, but I don't think any of it is really effective unless you absorb it with a keyboard at your fingertips.

Finally, on the subject of becoming more than a good programmer, I'll say this: software is like painting: anybody can learn to slap paint onto a surface well enough to paint a barn. It's an essential skill, but if you want to move above painting barns and learn to paint something like the Mona Lisa, then you need to learn a whole additional set of skills. Good programming is relavitely easy; good software design is hard.

--Jim

Re:Real Programmers Learn By Doing

[mooman]

ColdFusion (at least until you get the new MX version) still parses the page each time it's loaded, and has to scan through all your comments to make sure they get weeded out. It all adds time, nearly trivial time, but time nonetheless that is a non-factor for a compiled language where that all gets stripped out during the compile stage...

Re:Real Programmers Learn By Doing

[mooman]

Just because I have a web page that I haven't updated in 5 years doesn't mean I don't know programming. I've just been too busy to work on it.

It's an ironic comment coming from someone whose own webpage says "don't bitch about the web design. This is a quick hacked-together page...".

Oh well. I guess neither of us will hire each other....

Re:Real Programmers Learn By Doing

[SpamJunkie]

I won't pretend to know the best way to learn a new language but one of the better ideas to be more than mearly good is to read code. Find an open source project written in your language and read it. That's one of the best sources of wow! factor ideas.

The only problem I've had with this method is picking a good example project. All too often stuff on sourceforge is made by people that don't know their language that expertly or that don't write very nice code. Popularity certainly isn't the best way to pick an example project.

Re:Real Programmers Learn By Doing

[AppyPappy]

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.

Re:Real Programmers Learn By Doing

[Afrosheen]

That's one of many champion. The real page is at http://tuxbox.by-a.com/mdk_rpms or http://tuxbox.by-a.com/proftpd-howto or http://supermame.by-a.com . Thanks for visiting my amiga page :)

Re:Real Programmers Learn By Doing

[Carpathius]

I don't completely agree. I think the best programmers understand language paradigms -- OO, procedural, etc, and once those paradigms are understood, then all that's left is syntax.

You shouldn't write Java the same way you write C, shouldn't write C the same way you write Perl, but if you understand "best practices" in any OO language, you understand most of what you need to know about another OO language.

Except, of course, syntax.

A good programmer is going to understand the different styles required by different languages, is going to be able to understand which style is needed simply by the language definition, and is going to need to learn little more than syntax and what built in classes/functions are available.

For me? I'll hire the programmer that *wants* to jump in. He or she will probably need some kind of reference, but I'd much rather have the person who starts coding immediately than the one who insists that s/he needs to be trained in the language.

Re:Real Programmers Learn By Doing

[kzinti]

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.

That's called Trial By Fire. It's taught at the School of Hard Knocks. In a couple of years, you'll look back on this and laugh... as the attendant wheels you out of your padded cell for your daily session with the Software Recovery group. Enjoy!

--Jim

Re:Real Programmers Learn By Doing

[namespan]

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.

Re:Real Programmers Learn By Doing

[gutier]

I'm glad that the rest of the engineering world has advanced beyond the trial-and-error approach.

The mechanics of any technical trade are the absolute easiest to pick up. The "why" is a little harder and is the reason people have to learn professional designations before working on something substantial.

Re:Real Programmers Learn By Doing

[Tablizer]

(* [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:Real Programmers Learn By Doing

[Issue9mm]

Agreed. If every language had the type of documentation found at php.net, programming wouldn't be nearly as daunting a task as people make it out to be.

As for my experience, the PHP manual taught me all the perl I know, in an indirect method.

(Note, I am by no means a great perl programmer, but I've not been able to accomplish any task thus far.)

-9mm-

Re:It's amazing how far this language has come

[Skweetis]

What's great is that you don't have to use a crippled database like MySQL with PHP, there's no longstanding history or anything tying the two together. Much more capable databases (Postgres, JET, Oracle) can be used with the same amount of ease.

Amen to that. I would add a plug for ADODB or something similar for database abstraction, which makes PHP a bit more like the Perl DBI (no more separate sets of calls for each database type).

Next, while MySQL is great for small projects (and fast), it really is just a port of SQL to dbm files, and not truly relational, so it isn't great for large projects. As you mentioned, Postgres or Oracle fill this niche quite nicely (I don't really like the Oracle model for data types, but that is my personal bias). I could be mistaken here as I haven't used it much, but isn't Jet the file format used for MS Access databases? Access never seemed very robust to me.

Umm... why not just read the docs?

[Hollinger]

I learned all I ever needed to know about PHP from the PHP Manual. 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 will take you straight to the reference pages for MySQL.

Re:Umm... why not just read the docs?

[Shadarr]

I second that. When I was first learning MySQL I printed out the whole manual, which took up two binders. And then I mostly used the web version anyway because it's searchable. With PHP I never even bothered with paper because the website was so good. Not just the actual manual, but the comments people leave about the manual entries. Source code snippets, reasoning about why to use different methods, it's all right there and free. The only book I have is the O'Reilley Pocket Reference in case my network connection is down.

Re:Umm... why not just read the docs?

[elmegil]

I don't have the money or patience for a wireless network, and I don't have the time to exert the effort to put ethernet ports in every room of my 80-year-old house. It's awfully hard to read laser printed web pages (not to mention a P.i.t.A to print them in the first place) when you're lying in bed. Printed and bound books are an excellent resource for those of us who don't spend our lives with our eyes glued to a tube.

Re:The book

[HFXPro]

Oh my god I used "has" rather then "have" on that last sentance. Also lots of bad grammer in that post. *Sarcasticly says to self* >> Perhaps its time I take another English literature that my university forces me to take. All that English literature really helps me to learn proper programming techniques.

Oh shit I'm talking to myself again.

Re:The book

[geekopus]

I have to admit that I sympathize with this sentiment.

So many of my friends seem to think it's inevitable that .NET will be the only web platform out there.

It's really depressing. Microsoft won the public opinion war a long time ago (a clear sign comes when you ask an average user what kind of computer they have and they answer Office 98), and now they seem to be swaying developers as well.

Re:Using PHP and MySQL for a website...

[krammit]

I don't think that at all.

Why Not Java?

[cbernard]

If you are designing a new web app, why would you not use Java? The language not difficult to use, and the platform is objectively better architected that PHP.

Re:Why Not Java?

[Clay Mitchell]

Because it's not open source.

Seriously though, that's a very valid question. Aside from the fact that it's not GPL'd, it has a) better development tools, b) more libraries out there for the picking, c) better real live commercial support and d) you can use it for free.

I personally ditched PHP several months ago and aimed squarely at Java. God knows it looks better on a resume...

Re:Why Not Java?

[digerata]

Also, servlets, which are IMHO much better than JSP or PHP, can be used. Servlets more closely mimick the CGI paradigm the same way Perl does.

JSP and PHP are horrible for any type of application that has more than 1 developer and more than one revision of HTML layout. The integration of program logic with output display is the wrong way to do any type of large Web Application.

The creative staff that are responsible for designing the 'look n feel' of the application must coordinate closely with the developers. Each time the creative staff wants to revise something, or try out a new look, they must force the developer to reintegrate the display and logic.

And don't even think about incorporating multiple types of application styles based on who is logged in. Sure you could do it. But try and maintain it in a timely fashion!

The only real world solution to a large web application today is either J2EE or mod_perl.

Re:Why Not Java?

[Clay Mitchell]

That's why you want to stick with the Model-View-Controller paradigm.

You've got your data model and the classes that work in behind it, enforcing business rules and the like, then you have your controller servlet which says "ok, they want this, they need this page" and then you use your jsp's that just display information.

You take the processing away from the JSP and put it in the servlets/classes where it's faster and it's not such a huge pain for the designers to whack at it because it's just the occasinal <%=foo%> as opposed to a bunch of full fledged java code.

Re:Why Not Java?

[Hiro Antagonist]

I'm assuming that by "Java", you mean JSP; anyone who uses an actual *Java* application to implement a *webapp* needs to be shot. Repeatedly.

That being said, there are a few reasons, actually. I do some development work in Java, but I'm also pretty well-versed in a variety of other languages; including C, C++, Perl, Assembly (x86 and good 'ole 68k), and PHP (and shell scripting, of course). Compared to PHP, JSP is a *pig*. It eats up a much larger chunk of memory, more CPU time, and is IMHO a terrible platform for developing small web-based applications. JSP+EJB does have its uses, but not in the arena of small webapps.

This is where PHP really shines; it's very fast, has a small footprint, and is *much* easier to use and debug than JSP is.

So, for writing huge, enterprise-level apps, JSP+EJB is the way to go. For writing smaller apps; things that need to be written quickly and securely, I'll stick with PHP.

Re:Why Not Java?

[daf00masta]

<i>If you are designing a new web app, why would you not use Java?</i>
<br>
hm...why WOULD you want to use Java? Java is way to resource hungry, not Open Source, and though i think you mean JSP instead of Java, PHP is still easier to use, and it won't eat up your memory and use up mad amounts of CPU time.....
LAMP/LAPP/WAMP seems like one of the best options avaiable, anything other than JAva :D

Re:Why Not Java?

[GutBomb]

if the designer can't deal with a and some spread around in the content, they should not have a job as a designer. you can keep all of the logic in an include file that you call, and have the bulk of the file the designer gets as the HTML.

Re:Why Not Java?

[natbudin]

hmm... not to troll here, but you could say the same thing about Zope. I haven't yet found an easier language to use than Python, and Zope seems well-organized. And yes, there's a speed/memory overhead in comparison to PHP, but you'd get that with Java too. Plus, Zope is open source :)

Re:Why Not Java?

[Nept]

I agree regarding JSP - but the solution is to not put any logic in your JSP. For those who haven't used JSP, the problem is that the JWS has to compile the JSP page into a servlet prior to interpreting it, which of course makes it awfully slow. I think one of the best practices architecture is to do all of your business logic and database calls from a servlet/databean and then have the result set encapsulated inside of a javabean and returned through the session to the JSP page. The JSP page only is responsible for retrieving the JavaBean object from session memory and displaying the values. No heavy processing here.

When you say JSP+EJB, I couldn't agree with you more. Doing a JNDI call from a JSP page is suicidal, but I wouldn't reject webapps for this reason - just build a better architecture :)

I would recommend looking at the Java Pet Store Example from Sun's site. It's their official Enterprise Blueprint for Java Webapps and might help to convince you otherwise.

Personally, for using EJBs, I've found the most efficient implementation is to use (1) using some clever caching design patterns for the lookups (2) cloning design patterns to prevent all method calls from being remote calls and (3) to have the EJBs called from a servlet or other class file.
At any rate, Java technnology has its uses in the Enterprise. I've used PostNuke, PHPNuke and done some PHP coding on my own, but I wouldn't consider myself an expert, but I suspect it may not scale quite as well in a large application as a properly designed Java Webapp might.

Re:Why Not Java?

[gripdamage]

I agree regarding JSP - but the solution is to not put any logic in your JSP.

Exactly.

In another thread someone was complaining about PHP not switching database backends well. The problem was not PHP, but their coding practices. They were making raw sql calls in their pages instead of going through a database wrapper.

Similarly people embed their program logic in a JSP page, which is exactly what you aren't supposed to do, and then complain that it's slow and hard to debug.

JSP can be used like ASP (yech!), but isn't supposed to be. The whole beauty of JSP pages is that you can seperate the program logic from the page, which makes redesigning the look of pages a snap.

I find this approach works very well for any webapp, big or small.

Speaking of how easy it makes redesigning the web pages, in my current webapp I let people upload page templates and an interpreter fills in appropriate code (replacing simple keywords in the template).

Re:Why Not Java?

[swright]

I hate ASP as much as the next Linux guy here, but IIRC ASP isn't meant to be used much like that either (assuming use of VB in ASP that is). App logic should be done in COM objects and ASP/VB provides the glue between them and the HTML; just like what you said for JSP. Of course, with more capable languages under ASP thats probably not necessary.

Ah well, I'll stick to me PHP+Postgres any day.

ahem

[Pinball Wizard]

you PHP weenies(kidding) can't hog the 'P' part of the LAMP acronym all to yourselves.

The 'P' in LAMP refers to Perl/PHP/Python.

Re:ahem

[BdosError]

So, maybe the 'P' in LAMP stands for "scriPting"? Or maybe "pScripting", with a silent 'P' ("... as in 'pool' " - Benny Hill).

Re:Using PHP and MySQL for a website...

[AllMightyPaul]

Slashdot uses MySQL. I point you to their FAQ: What kind of hardware does Slashdot run on?

But MySQL doesn't do UTF-8...

[andersen]

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?

Re:But MySQL doesn't do UTF-8...

[andersen]

I need it because large chunks of the content I intend to store in the database and need to be able to search through are encoded in UTF8. So I can either pre-process all that content (many many gigabytes of UTF8 crap per database) using iconv() to convert it all into multi-byte, or use a database that can natively store UTF8.... The latter looks much more attractive to me.

aminamals

[X_Caffeine]

Chapter this, section that, blah blah, how about the important stuff: What kind of animal is on the cover?

Re:aminamals

[Anonymous Coward]

platypus

YAAMPB!

[MattRog]

Lord, just what the world needs. *Yet Another Apache, MySQL, and PHP Book*. Anyone else thing eleventy-billion of these things is around (eleventy-billion - 2) too many?

Re:YAAMPB!

[McSnickered]

Actually, just 2.5 years ago there were only 2 or 3 books on the subject .... and they SUCKED! I bought one, I know. So I'm pleased to see lots of GOOD books coming out on the subject!

Only reference you need for PHP

[Zach978]

Is right here.

Book has a missleading title

[Neil Watson]

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.

Re:Book has a missleading title

[elmegil]

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.

Re:Book has a missleading title

[neafevoc]

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.

Re:Book has a missleading title

[ceejayoz]

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.

Transactions?

[rochlin]

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!

[Just Some Guy]

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.

Re:I *hate* DB programming in PHP!

[the_radix]

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, 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!

[AC-3]

Someone needs to introduce you to the concept of database abstraction in PHP. Code your classes to the DB class generic calls and then when you need to switch DBs you just swap out the db class with the (Oracle|Postgres|MySQL|Whatever) class and you're good2go.

Re:I *hate* DB programming in PHP!

[Anonymous Coward]

Take a look at PEAR's DB abstraction layer:

1. PEAR

Re:I *hate* DB programming in PHP!

[Just Some Guy]

Unfortunately, the project was started before any of the current abstraction layers existed (or were usable, at least). Either you used PHP's builtins, or you didn't connect at all.

Were we to start now I would do things much differently, but I still contend that by the time you've started installing abstraction layers, etc., then you might as well use Perl from the beginning.

Re:I *hate* DB programming in PHP!

[MattRog]

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.

Re:I *hate* DB programming in PHP!

[mborland]

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.

Re:I *hate* DB programming in PHP!

[reddog1]

Not so true. There are PHP libraries out there that exist to serve this purpose. Include the library, tell it which dB you are using and all the rest of the code is the same. Check out ADODB. To see it in action, check out PostNuke. I find it rather nice :-)

Re:I *hate* DB programming in PHP!

[truefluke]

The DBI isn't included in standard Perl. You have to download it from CPAN. Unless you've installed (or someone has for you) Indigo or NuSphere.

Re:I *hate* DB programming in PHP!

[SpamJunkie]

Perl's DBI is very nice.

But I have to mention Python's DB API2. It works very well also. Moving between compliant DBs is quite easy - I've moved from MySQL to Postgres twice now with very little effort.

All I need now is a good mod_python, or the like.

Re:I *hate* DB programming in PHP!

[Lando]

Hmmm,
Comparing PHP with Visual Basic might not be too far off. Basically the reason I started writing in PHP was that mod_perl was not available at the time and kicking off cgi scripts was becoming a royal pain in the butt.

PHP is a focused language though and doesn't have the full functionality of perl, but then again it is easier to pick up than perl. I'd agree.

As for MySQL comparied to access. They aren't compariable in the least... First and formost MySQL is a database something that I wouldn't even consider Access for. Access is slow clunky and doesn't or at least didn't support SQL standards. MySQL is one of the fastest databases available currently, for most sites it can do anything that they require.... The only thing Access has going for it is the user interface... The tools for developing new databases quickly for non-admins can be helpful at times..

Hmmm, sorry for the lack of details, but while I think your comparison of php and vb is reasonable, access just doesn't compare to mysql as a database.

Re:I *hate* DB programming in PHP!

[eddy the lip]

Were we to start now I would do things much differently, but I still contend that by the time you've started installing abstraction layers, etc., then you might as well use Perl from the beginning.

My first thought when I saw the Xtemplate class was "hmm...this looks a lot like what I used to do with perl and Sam Tregar's (excellent) HTML::Template module." I say "used to" because there were a couple of projects around here that had PHP/MySQL as a requirement, and by the time those were done we had a large reusable code-base....and here I am, slinging PHP instead of my beloved Perl.

There is one thing that makes PHP more attractive for me. We deploy sites on hosts all over the place - we never know what's going to be installed. When you're using Perl, you never know what you're going to be able to use - is DBI installed, AnyDBM, anything? With PHP, you know you've got a database, and there's a 99% chance it's MySQL.

One thing I'm really looking forward to with Perl 6 (to go on a tangent) is this promise of SDKs...if sysadmins can just grab the "Web Site Development SDK", I may yet get to return to it.

Re:I *hate* DB programming in PHP!

[Just Some Guy]

Zope is a right server-scripting choice for a serious web-project.

You're preaching to the choir. My client is consolidating several web and database servers, and their webapps are variously running against InterBase, PostgreSQL, and MySQL.

Today I moved a whole site from MySQL to PostgreSQL by adding a ZPsycoDA adapter and pointing the ZSQL object at it. After 10 minutes of work, I'm done, and the site works flawlessly.

Re:I *hate* DB programming in PHP!

[pi_rules]

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.

Re:I *hate* DB programming in PHP!

[horza]

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.

Re:I *hate* DB programming in PHP!

[mborland]

To start out with, I appreciate the comments.

By un-portable, I meant somewhat inelegantly that you can't port your code to different databases without serious rework because there's no database abstraction. Definitely, you're right that it runs on more platforms than ASP does (don't cry to me about ChiliSoft...it's a load of crap)!

As for using it to do command line/desktop apps...I suppose I hardly consider it a good language, for the same reason as above (no true abstraction) and the fact that it's really just a scripting language intended for web servers. If someone told me they'd built their desktop app in PHP I'd be concerned that they were just a web hack who couldn't be bothered to learn a more appropriate language.

Finally, yes, we agree about the smaller site use for PHP. I suppose the only reason I brought that up is that I've met with a number of zealots who try to convince me that all sites should be written in PHP--and often a sentiment on Slashdot.

Re:I *hate* DB programming in PHP!

[Jack9]

I've always used a generic database object in PHP. I start every document with a config.php that defines the database, the paths, etc and then assume my generic objects and function calls will work through predefined wrappers or autodetection. If something breaks, PHP debugging is a breeze =)

# we always store the last result in the obj but
# *can* catch it if we want and it's supported
$result = DBobj->doQuery("SELECT * FROM FOO");

Re:I *hate* DB programming in PHP!

[Malcontent]

"you can't port your code to different databases without serious rework because there's no database abstraction."

Well this is mostly a lie. There is no database abstraction layer in PERL either DBI is a library. There is no database abstraction layer in VB or C++ either ODBC and ADO are libraries. Same with python.

So what you meant to say was that as far as PHP is concerned it's no different then VB, PERL, python, or C++ when it comes to database abstraction. You have to download and use some external library.

"Finally, yes, we agree about the smaller site use for PHP"

If you are hack then all you are going to do is small sites anyway (and bad ones at that). The fact remains that there are some HUGE sites that use php. You might want to look at sourceforge or insight.com as examples. PHP provides you with everything you need to build large complex web applicatons that are object oriented and easy to maintain. Maybe you ought to look into some of the more advanced aspects of it.

Re:I *hate* DB programming in PHP!

[fferreres]

(something the Java guys obsess over, something the Microsoft guys and the PHP guys don't seem to consider much).

All the Java apps I have tried run so slow I can't even use them. Great, It's well designed and I *could* run it anywhere, but would I *want* to?

I am talking about LimeWire, Phex, PanoTools and apps of that size (well, Panotools is great, as slow as irreplaceable).

Re:I *hate* DB programming in PHP!

[Tablizer]

(* MySQL is one of the fastest databases available currently, for most sites it can do anything that they require.... The only thing Access has going for it is the user interface... The tools for developing new databases quickly for non-admins can be helpful at times.. *)

There is a web-based interface to MySQL called PhpMyAdmin (do a web search). I think it is OSS. It is a little clunky, but it beats the MySQL command-line. (I don't have anything against command-lines in general, I just don't like doing DB management on one. Rows and columns are best managed using rows and columns.)

Re:I *hate* DB programming in PHP!

[Lando]

phpdatabase is a great little script, but it really doesn't provide the functionality of access.... Grin

Actually I used to be a MCP in access 94-97, Most of my knowledge of access and the jet database comes from that time... Until Microsoft came out with MSSQL 7.0 they didn't have a proper database, and I doubt that they have put that technology into access...

Anyway, I don't work with Microsoft products much anymore, but I do miss the ease of access. But power, flexibility, security and costs are a bit more important.

Re:I *hate* DB programming in PHP!

[mborland]

I don't know why I'm responding to your inarticulate flame.

First of all, my original post actually was talking about how PHP can be good for many reasons, but whatever...

Well this is mostly a lie...ODBC and ADO are libraries.

Oy.

Yes, ODBC, ADO and JDBC are libraries. Libraries make it really easy to take your code and port it from database A to database B, which is actually a good and common thing. I do this frequently. Frankly, in my line of work it's a good way to move organizations off of dependencies (like porting away from SQL Server)...they make it easy to run the database in SQL Server, Sybase, Oracle, Postgres...etc. It's not actually that hard to port mid-sized apps to different databases. The fact is that in PHP the built-in functions do not have similar calls (by name or in their function) between different databases...this is a good thing OR a bad thing, depending on how you look at it. That was the point of my original post.

If you are hack then all you are going to do is small sites anyway (and bad ones at that). The fact remains that there are some HUGE sites that use php.

Goodness. Where did you learn to communicate? Insult what you do not know? Oh, wait, this is Slashdot. I'll go tell all the people for whom I built useful, profitable sites that I was called a 'hack' and have been demoted to making bad, small sites.

Maybe you ought to look into some of the more advanced aspects of it.

I agree, obviously some large sites have used it, true of pretty much any technology. I will look more at PHP, although if most developers are as ire-ridden as you I doubt I'll join that community.

Re:I *hate* DB programming in PHP!

[Malcontent]

"The fact is that in PHP the built-in functions do not have similar calls (by name or in their function) between different databases...this is a good thing OR a bad thing, depending on how you look at it. That was the point of my original post."

Apparently you are more dense then I thought. Ok let me try to explain it again. If you were using perl then you'd have to download a library called DBI. This library enables you to write database independent applications. If you were using Visual Basic, C, C++, python etc you'd have to do the exact same thing.

If you are using PHP and wanted to write database independent applications you'd have to do exact same thing. You'd download phplib, PEAR, ADODB, metabase or any database abstraction library and write your application. I am of course presuming that someone of your intelligence level can actually seek, find, download and install libraries for PHP. I am making this presumption because you are so far exhibiting profound ignorance of the existance of these types of libraries. I hope that this post can ease some of that ignorance. If you need the URLs of where you can download these libraries please ask and I will gladly help you out.

" I will look more at PHP, although if most developers are as ire-ridden as you I doubt I'll join that community."

I don't think anybody will cry if you decide to use something else. The PHP community is thriving despite your absence and will continue to do so with or without you. Nine million web sites have decided to use it and I don't think any of us will panic because mborland doesn't like us. In fact it might be better for us if people who are unable to do simple searches on google stay away.

However in the spirit of doing my part to ease your ignorance I would like to present you with this link. Here you will find many database abstraction layers which you can download, install and use.

phpclasses.org

[djaxl]

People keep mentioning php.net. I have to put my vote in for 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

[saberworks]

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.

Re:Big problem with most PHP Books

[eddy the lip]

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.

Re:Big problem with most PHP Books

[ProfKyne]

The biggest problem with all the PHP books out there is that they don't talk about software design or good coding practice.

This is so true. I basically taught myself how to program from scratch, never having had the sense to study it when I was in college. PHP was my first language. While every PHP book has its obligatory chapter on OOP, and of course they say stuff like "always comment your code", it was only once I started to learn Java that I started to pick up on "big picture thinking" and using objects to keep everything nice and neat. And none of the PHP books even mention phpdocumentor or phpdoc, which have been amazing (basically JavaDoc for PHP).

(I realize OOP isn't for everyone but for a small web application [not just a guestbook] it really helps to use OO design)

Re:Big problem with most PHP Books

[Tablizer]

(* it was only once I started to learn Java that I started to pick up on "big picture thinking" and using objects to keep everything nice and neat. *)

BullcrOOP!

What specific software engineering problem did OO "fix"?

OO is NOT more change-friendly. I challenge you to provide specifics. No more cliches and double-talk. Talk with code and not slOOgans.

Where's the evidence!

I might be an anti-OO troll, but I am a
*correct* troll. The BS surrounding OO is simply amazing.

Give me realistic details, and I shall slay your OO code WRT "change-friendliness". (At least break even.)

oop.ismad.com

Re:Big problem with most PHP Books

[ProfKyne]

What specific software engineering problem did OO "fix"? OO is NOT more change-friendly. I challenge you to provide specifics. No more cliches and double-talk. Talk with code and not slOOgans. Where's the evidence! I might be an anti-OO troll, but I am a *correct* troll. The BS surrounding OO is simply amazing. Give me realistic details, and I shall slay your OO code WRT "change-friendliness". (At least break even.)

Um, I seem to remember posting something about how it helped me and not necessarily everyone, to use OO programming. Yes, it did. Even if only to provide a convenient reference for pointing to a "User" or "Company" in the application I wrote.

Besides that, it sounds like you have other problems pent up inside you. You must be a failing CS freshman or something -- I never brought up the subject of software engineering problems (since I'm far from an engineer) or change-friendliness. Take it up with your professor or your advisor if you have such a bone to pick.

Re:Big problem with most PHP Books

[Tablizer]

(* Um, I seem to remember posting something about how it helped me and not necessarily everyone, to use OO programming. Yes, it did. Even if only to provide a convenient reference for pointing to a "User" or "Company" in the application I wrote. *)

Well, let's see it. Without scrutiny, how do you know that your approach is the *only* way to acheive whatever it is you acheived? I have seen other OO fans do stuff where it was discovered they were not very good procedural/relational programmers (or using lame languages), and attributed their lack of skill to the paradigm being faulty.

I am not saying that you necessarily fit that profile, but that without seeing it, one cannot rule it out.

(* Besides that, it sounds like you have other problems pent up inside you. *)

OO is overhyped regardless of whatever "pent up" problems I might have. I never see good evidence; only vague cliches, mantra, and toy examples that don't fit change-patterns of the real world.

I will agree that *some* people may think better under OO, but one should not extrapolate that to all developers unless good objective evidence is presented for its alleged superiority.

Getting around personal weaknesses and/or bias of either party is why I want to see actual examples of OO being "better" than p/r. That way neither side has to take the others' word for it.

You game?

Re:Big problem with most PHP Books

[ProfKyne]

Well, let's see it. Without scrutiny, how do you know that your approach is the *only* way to acheive whatever it is you acheived?

That's just the thing. I never meant to suggest that my approach was the *only* way to achieve it. Only that it helped me to use objects.

I have seen other OO fans do stuff where it was discovered they were not very good procedural/relational programmers (or using lame languages), and attributed their lack of skill to the paradigm being faulty.

I'll go you one better than that -- I'll wholly admit to being "not very good" at procedural/relational programming. Or even object oriented programming for that matter. I'm really not a good programmer! I'm trying, and learning, but I'm not claiming to be something that I'm not.

I am not saying that you necessarily fit that profile, but that without seeing it, one cannot rule it out.

I assure you, I fit the profile. Me = not a very good programmer, just someone with a few PHP/database skills.

OO is overhyped regardless of whatever "pent up" problems I might have. I never see good evidence; only vague cliches, mantra, and toy examples that don't fit change-patterns of the real world.

That's exactly what I'm talking about though. You're pulling your own preconceived notions about what I'm saying into the conversation. All I'm saying is that it made my life easier.

I will agree that *some* people may think better under OO, but one should not extrapolate that to all developers unless good objective evidence is presented for its alleged superiority.

Thank you. Now that we have both understood that we're really on the same level (we agree that one should not try to make a blanket statement like "everyone should use OO", which I did not), let's leave it at that.

ADO for PHP

[Kamel Jockey]

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

Re:ADO for PHP

[hendridm]

You can access ADO as a COM object as well.

Re:Using PHP and MySQL for a website...

[Galaxie]

You either don't know php, don't know enough to be effective, or are one of those people who requests that they need 3 webservers and 3 database servers just to put an average of 20 to 30k of information on a webpage per hit.

Just for reference: http://apachetoday.com/story/2002-06-04-001-06-PR- DT-PH.html

php is being used by thousands of large corporations to run some very vital data, usually off of PostgreSQL, mySQL, or in some cases Oracle.

damn man.. that was a stupid post..

Re:Using PHP and MySQL for a website...

[Starship Trooper]

Slashdot uses MySQL.

And that's supposed to impress me? The traffic Slashdot gets is insignificant compared to top-tier sites like eBay, Amazon, CNN or even microsoft.com. Even under Slashdot's rather minor load, the site goes down with alarming frequency, despite hosting MySQL on a quad-Xeon machine! Oracle on a box half the size of their MySQL server handles roughly the same amount of load without needing to have scheduled downtime every night at midnight (to cope with MySQL and mod_perl's Swiss-cheese memory management). MySQL is a toy database (no transactions? no subselects? no row-level locking?!), and Slashdot is a toy website in comparison to sites running real web applications. MySQL isn't even a consideration for serious business.

Re:Sorry to piss on your corn flakes...

[baldass_newbie]

You're right. Sorry 'bout that.
Two week old baby. Up all night.
Need Sleep...

Rasmus' is the best PHP book I've ever read,

[TheTomcat]

I just finished reading Programming PHP, 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

Database abstraction classes are available

[UsonianAutomatic]

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 or ADOdb. Either one implements a standard set of methods for interacting with databases regardless of the backend.

question - not trolling

[Ender Ryan]

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.

Re:question - not trolling

[thenextpresident]

First, my thoughts on PHP v.s. Perl:
http://www.phpcomplete.com/devblogs.php?blo gid=4

For me, the simple fact is that PHP and Perl can both be used in each their own areas. I find PHP better for the web as it has built in functions simply made for it. However, when I need scritping power or server side programs, I turn to Perl.

PHP offers up a very easy to use syntax (comparing it to Perl's ability to obfuscate) and is therefore easier to learn the Perl by many (read Not everyone, but most people I know).

I use both happily, and when faced with PHP v.s. Perl, I say "use whatever you are happier with".

Re:question - not trolling

[FamousLongAgo]

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.

Re:question - not trolling

[gimpboy]

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

if someone posts a link to pear, keep in mind it's nowhere near as polished and feature rich as cpan.

Re:question - not trolling

[horza]

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.

Re:question - not trolling

[eddy the lip]

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.

Re:The Web is Dead

[Ironfist_ironmined]

goddammit M$, rig C|Net polls all you want but dont go trolling slashdot!

Re:Using PHP and MySQL for a website...

[Starship Trooper]

You either don't know php, don't know enough to be effective, or are one of those people who requests that they need 3 webservers and 3 database servers just to put an average of 20 to 30k of information on a webpage per hit.

No. Quite the opposite, really. No matter how "effectively" one codes PHP, there's no getting around the facts that the language is slow, the syntax disgusting (using C-style string manipulation in an interpreted language is just STUPID), and that ASP-style mixed HTML and scripting languages encourage slovenly, disgusting coding practices. While mod_perl is bad enough, if Slashdot were coded in PHP it would need about twice as much hardware to handle the equivalent load, in order to cope with PHP's terminally laggard interpreter.

php is being used by thousands of large corporations to run some very vital data, usually off of PostgreSQL, mySQL, or in some cases Oracle.

Replace "large corporations" with "fly-by-night dot-bomb VC leeches who can't afford a competent Java servlet programmer" and you'll be closer to the truth. All of the most frequented sites on the net either use Java servlets or ISAPI modules, because those are the only systems fast enough to handle load on the level of eBay or Yahoo. By replacing my company's rusted old PHP-based site with a fast, efficient Java servlet, we were able to repurpose half of the boxes in our load balancer, and the site still manages to handle at least 30% more load than the old PHP server. PHP wastes hardware and money; it's neither scalable nor maintainable.

Re:Office 98 is a Mac.

[geekopus]

No, my example was perfect.

The point is that the user can't tell the distinction between Windows and Office, and they think that unified thing *is* their computer.

I've been told that exact quote before, when what the person meant was "Office 97 and Windows 98".

I knew I should have explained that, but I figured that everyone would understand.

Re:Using PHP and MySQL for a website...

[MattRog]

Did your company evaluate products such as the Zend Accelerator?

They seem to indicate it works well. Although our site's Case Study is a bit out-dated it still provides significant value, esp. when considering the cost of a J2EE app server and the like.

It's easy

[Anonymous Coward]

That's basically it. Someone who has never programmed before can get started with php really quickly and easily. First you can do a simple , then you can move into the fun conditional world of if and else. In no time, you have a little php application running. Throw in some mysql access, and voila. When you need some more advanced features, they're there for you. Lots of times I've thought "I wonder if PHP can do x..." and then I look, and indeed it can.

Perl often seems quite scary to beginners. PHP doesn't.

Re:It's easy

[just4now]

About two years ago I put together an Apache+PHP+MySQL+Oracle prototype. At the time, I looked at Perl but it seemed to have a steep learning curve - steep meaning that I'd have to spend a good chunk of time before I was able to write anything useful. I was able to quickly use PHP to execute dynamic SQL against both MySQL as well as Oracle.

Cost was a factor here - the organization spent about $10.00 for the RedHat 6.x cd-rom - and I could have downloaded it if I had the time. I used a retread PC from one of our local offices.

Having worked with Cobol, C, Fortran, Basic and then SQL and PL/Sql, I did not need more obscure stuff (like C++) but something almost any coder could pick up in a short period of time. PHP seemed to be the answer back then. PHP files don't need a special cgi-bin directory or other stuff - link Apache with PHP and your done.

Like any language, Perl has it's place. But sometimes another tool is better for the task at hand.

Agreed. Another one I used:

[twilight30]

MySQL/PHP4 Database Applications, 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.

Re:Agreed. Another one I used:

[ProfKyne]

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.

It's a good book to get across the important concepts in dynamic site design, but it completely sucks if you're starting from scratch with MySQL and PHP. I think there were something like twenty serious typos or publishing mistakes in the first fifty pages.

A good book, ruined by poor publishing or editing.

Re:Agreed. Another one I used:

[twilight30]

[Welling & Thomson:] A good book, ruined by poor publishing or editing.

You summed it up better than me!

I'll say, though, that I was in the same boat: no previous experience with PHP or MySQL. Checked the errata site. Before even buying the book in the first place, I read the user reviews on Amazon. I followed W&T's advice to look at both online references, and in total, learned a lot more than just the book's material (well, OK, I felt more comfortable when I ran into problems).

To anyone looking at this subject area, do check out this book. It *is* good once you get past the first fifty pages.

I reviewed the companion to this book a while ago

[truefluke]

You can read my quick (5 minute) review of Programming PHPon www.signalnine.com.

I haven't had the chance to look at this particular book yet but I appreciate this review. Good job. Perhaps I shall pick it up, or at least park my butt at Borders bookstore and give it a more thorough glance the next time I am there.

Re:Here's a review...

[grokBoy]

I don't think that was a troll, to be honest. I'd rather write a decent perl script any day.

PHP worries me in its complexity - with that many compile-time options to choose from there are bound to be many more security holes around the corner in some of the more obscure code.

That's not to say I disapprove of PHP, I just wouldn't use it myself.

Re:Using PHP and MySQL for a website...

[Starship Trooper]

Well, if you don't want to listen to me, let the nnumbers speak for themselves. Resin+Apache pushes out twice as many pages/sec on a database-backed site than PHP can.

Re:Using PHP and MySQL for a website...

[MattRog]

I can attest to other products' robustness as well. We run Sybase ASE 12.5 on a dual (run-of-the-mill PIII 1GHz) CPU linux box. I am not sure what kind of traffic Slash gets, but I do know on sites which keep track of the number of online users that get slashdotted are lower than our typical user-load periods.

Plus, we don't have to take the DB offline to perform BACKUPs and other such nonsense. Replication is better and faster, java and XML support, etc. etc.. Sometimes, not always, but sometimes you get what you pay for.

So is LAPP (Linux, Apache, PHP, PostgreSQL)!

[jocknerd]

This is what I'm using here at work to develop a job description and application system for the Personnel department that I work for.

Re:So is LAPP (Linux, Apache, PHP, PostgreSQL)!

[MrEfficient]

I also work in a State Personnel Department. I'd be interested in hearing about the system you're developing, especially concerning the job descriptions. Our state is also developing an online application for people to apply for state jobs. You can email me at mb_chandler@hotmail.com if you're interested in discussing it.

Re:PHP == Perl for girls

[axxackall]

Let me continue:

• PHP is for girls
• Perl is for boys
• VB is for toddlers
• C is for bikers
• C++ is for biker-women
• Java is for biker-managers
• Lisp is for artists
• Scheme is for lazy artists
• Prolog is for mathematicians
• Python is for construction builders
• Tcl is monks-builders
• XML is for hippies
• RDF is for buddhists
• XSL is for bishops
• ... to be continued ...

Stop the Monkeys!

[ignatzMouse]

Please, no more PHP/MySQL books.

embedded perl

[SCHecklerX]

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/

Re:embedded perl

[frankie_guasch]

I agree, mod_perl + HTML::Mason is a win for developing big sites.

Re:PEAR DB abstraction

[gimpboy]

i lost ``touch'' with php so to speak about a year ago. i gave php up for perl a while ago. does the pear db now come with a conveniant way to install it, or does it come with the main php disto? one of the nifty things about cpan is how easy it is to install perl modules. cpan also represnets a unified development arena for the perl community. pear was trying to do this but i dont think it was having the same effect. that was one of the really frustrating things about php.

which db abstraction layer should i use?

there were quite a few to choose from at the time, and none of them were as mature as dbi.

where should i go to find pre defined modules for php?

there was no central location for this.

the lack of uniformity in the php community can be very disheartening for someone like myself. this might have changed in the last year or so, but when i switched from php to perl it really lacked momentum.

Re:Using PHP and MySQL for a website...

[Anomolous Cow Herd]

Don't forget a complete lack of stored procedures and triggers. Last I heard about it, they said they'll implement them "sometime" using Perl (!).

PHP Templates

[jwinter1]

If you are using PHP in the usual way, that is, to generate dynamic web sites, you need, absolutely need, to use templates. Any other way will eventually be impossible to maintain as your project increases with complexity.

Our department uses a simplified version of PHPLib's template.inc, and I cannot count the number of man hours it has saved us. There're a million reasons to use templates, separate logic from presentation, let Web designers create templates and let Web coders create PHP code, etc., and only one reason not to: ignorance.

"Gentle learning curve"?

[Tim Ward]

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?

Re:"Gentle learning curve"?

[horza]

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.

Re:"Gentle learning curve"?

[namespan]

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.

Re:"Gentle learning curve"?

[ed1park]

or up a mountain!

Re:"Gentle learning curve"?

[bethel]

There is something wrong with your english. Steep means hard/difficult, gentle means easy. Why the heck did you get a rating of 3 for this comment?

Other option: openACS

[Cirkit]

I'd like to recommend the excellent openACS 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. :)

japple

[Thrakkerzog]

japple is much easier than php (for me, at least), and has a solution which splits the scripting language from the HTML.

check it out at japple.org

I've been very impressed so far.

Web Applications

[namespan]

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.

zope stats

[mgkimsal2]

Give me stats please - I can never find anyone who gives actual numerical benchmarks on Zope/python in terms of capacity. Give hardware numbers and sample code and benchmark results for how well it held up. 'still good enough' performance just doesn't sound all that convincing. Everything I've seen about Zope points to 'oo' database as being the primary database. People needing to interface with standard relational databases seem to be SOL - how right/wrong is that?

'real OOP' - PHP is 'good enough' at OO for most projects (if 'good enough' is sufficient reason to use Zope, it's sufficient to argue for PHP too).

Zope *needs* to have better presentation - we've installed it a few times and it's always confusing as sin, with no good documentation.

Re:zope stats

[cjpez]

Zope actually makes dealing with plain ol' relational databases REALLY easy. The primary database is, yes, OO, but I've built quite a few applications in Zope that deal primarily with a relational database. The OO stuff is really great for programming the actual application, and then the data can get stored away in the relational database. Really cool funky application stuff.

I do agree about documentation, however. I'm a total Zope freak; I think it's by far the best application server environment out there, but the documentation has always managed to be really boggling. There's this really bizarre learning curve involved, and for some reason they've never seemed able to get past it. Once you understand Zope, it's great, but if you don't it can be pretty hellish. At least the mailing lists are generally good sources of info if you make some effort to sound like you know *sort* of what you're doing. :)

As to benchmarks and stuff, I know that there were some tests done some time ago with Zope vs. Tomcat vs. something else, but I've long since lost the links. Search the mailing list archives, should be in there. (Of course, as the advocate, I should really be the one supplying the links, eh?)

Re:zope stats

[mgkimsal2]

Not to press the issue too much but...

If the stuff is pulled from and stored to a relational DB, why not just use a language which is more suited to dealing with relational stuff? Zope seems to thrive on OOdb stuff, and the relational, while possible, is an 'oh yeah, that too' thing (again, talking appearances).

Yes, you should supply the links. :)

Comparing against Tomcat - at least earlier versions - is like shooting fish in a barrel. I'd be more interested to see it go against a BEA app, or a well-built PHP apps (not that many exist tho!) :)

Re:zope stats

[cjpez]

Hey, press all you want! :)

Speaking from experience, the way Zope ties into the relational databases is anything but "oh yeah, that too." It's kind of difficult to explain how the two can work together. First off, the ZopeDB really isn't OO in the way that you're thinking it is. There's many similarities, but if you try to make it work exactly like the OO model in your head, you'll probably end up banging against some walls. When you go to http://host/foo/bar/baz, "foo" "bar" and "baz" are all objects in the ZopeDB, and they aren't necessarily "heirarchical" in the way you might think. Ie, the "directory" structure could look like this:

• foo
  • baz
• bar

So when Zope's rendering "baz", it'll look at baz's "acquisition path," which will look at "bar" and "foo," and depending on what those objects do, the behavior of "baz" can be radically altered. Like "baz" could be some kind of administrative plugin object, and if you simply add "baz" into the acquisition path, and instead of getting the data-entry screen, it'll launch you into an administrative version of the screen that's still being sourced from the same place, and does extra authentication and stuff.

It's really beyond the scope of a Slashdot post to fully go into, however. :) The OO stuff is just really wicked-cool to code in.

As for the speed thing, it is really difficult to compare just because of all that Zope's doing. For every web request you make into Zope, it'll be doing authentication, persisting changes in the Zodb, doing some version control stuff, talking to the relational database, adding up all the acquisition paths and so forth . . . It's doing a *lot,* and it makes it difficult to compare to other packages because when you get to that level of complexity it becomes harder to say which is "better." Like, something might be running faster, but you don't get all the cool benefits of Zope's object acquisition, or possibly the really fine-grained level of security and permissions that Zope has built in . . . And are the replacements in the competing package "better" or "worse?" It's really hard to say. There are things you can do in Zope, programming-wise, that would be nigh-impossible in other systems, just as there are probably things in other systems that would be nigh-impossible in Zope. So it's difficult to tell.

But I'm rambling now. :)

PHP and XML

[horza]

Now would be a good time to ask for beta testers of a new XML module for PHP. 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. So simple it only took me a couple of minutes to write a XML-based guestbook. Another example is here. Install instructions are on the site, feel free to have a try and give any feedback.

Phillip.

we need books about PGSQL

[axxackall]

I would recommend the following books about PostgreSQL and web development:

• PostgreSQL and XML (Xalan, 4Suite)
• Java and PostgreSQL (JDBC, Struts, JBoss)
• PostgreSQL and Zope
• Web Warehouse with PostgreSQL

If you have any ideas, proposals and suggestions - my email is axxackall@yahoo.com

Why not mod_python and MySQL?

[elysian1]

I've used both php and python and I must say that python code is WAY easier to maintain.

Re: reminds me of "C Bible" = "build calculator"

[fferreres]

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.

You don't need OO crap to wrap DB operations

[Tablizer]

(* [Unfortunately, the project was started before any of the current abstraction layers existed] You could have written your own. It whouldn't have been that much effort. *)

Exactly!

You don't even need OO. Wrap it in functions. You can also consolidate many things so that if 90% of your code uses the same database or connection handle, you don't have to keep referencing it over and over. Open them all in a single function.

Use optional named parameters if you need to deviate from the norm (std. connection, etc.) on occasion. That way you don't clutter up 90 percent of the calls for the 10 percent that deviates. Optional named parameters are great for that kind of thing. (I haven't used named parameters yet in PHP, so I don't know if they have any limitations).

Don't fall for all that bullshOOt that only OOP can protect you from DB vendor changes. Those OO book authors simply don't know how to use procedural/relational programming correctly. They had a bad experience in C, and tossed out the baby for OO.

oop.ismad.com

Re:You don't need OO crap to wrap DB operations

[rycamor]

> oop.ismad.com

Hehe... some fun stuff there. I especially agree with your take on the limitations of trees. One of my pet peeves.

If you are into thinking about set mathematics, then you might enjoy reading from the guys at http://www.dbdebunk.com/. They also have some very pointed discussions about OOP and OODBMS.

> You don't even need OO

True enough. Abstracting a database layer in PHP is child's play, with or without OO. In fact, even if you use one of those shiny OO abstraction layers that are so popular in PHP now, you should really be doing some project-specific abstraction anyway. At least, for larger, complex projects.

Re:COMMENT STOLEN FROM AMAZON DOT COM

[Tablizer]

What is wrong with that as long as it is the *same* author?

Guilty until proven innocent?

Psuedonames are all over the web. You don't know that they are different persons (yet).

JET vs. MySQL?

[Tablizer]

(* What's great is that you don't have to use a crippled database like MySQL with PHP, there's no longstanding history or anything tying the two together. Much more capable databases (Postgres, JET, Oracle) can be used with the same amount of ease. *)

JET less crippled than MySQL? (I assume you mean MS's JET. Is there another with that name?)

It wouldn't even run if it was that bad.

The only nice thing about JET is that it is easy to transfer the database data and schema together in one file. Beyond that, it is the royal pits.

I wish an open-source JET-like engine and/or file format caught on. (But fixed)

Re:Using PHP and MySQL for a website...

[Verizon Guy]

You pro-Free Software people can be so brainwashed that you are retarded.

eBay runs IIS. Hear that? eBay RUNS IIS!

The site cgi.ebay.com is running Microsoft-IIS/4.0 on NT4/Windows 98.

Grow some pubes, please.

Stupid pedantic correction

[noda132]

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.

Re:The Web is Dead

[Tablizer]

I don't know who moderated the above message down (zero), but it was uncalled for.

They were *not* promoting MS, but merely giving their opinion that MS will kill the standards and or the market.

That is a legitamate opinion. MS has killed other things. (I don't necessarily agree with it, but it is an understandable viewpoint based on past history.)

Their sig also suggests that they are a Perl fan anyhow, and not an MS fan.

Bad moderator!

Re:PHP == Perl for girls

[Tablizer]

(* Perl is for boys *)

Perhaps in the sense that boys bust in town, knock the girl up in wild passion, then skip town and leave a cryptic mess for somebody else to take care of for the rest of the "project".

I don't care, use whatever language you like as long as you don't shuv it down other's throats.

BTW, I don't like Perl's habit of using arrays of pointers to arrays to create collections. If you have to change the implemenation of the collection to get say more columns or indexes, then you have to overhaul a bunch of code. Better to wrap collections into some scalable API so that changing the guts does not create more consulting hours to line your pockets.

Its the ISPs

[KIngo]

The vast majority of ISPs offer PHP+MySQL as part of their low-cost solutions and not PHP+(any other RDBMS). That's why the vast majority of readers will be interested in excactly this combination.

Re:PEAR DB abstraction

[gimpboy]

actually if you install the cpan perl modules it has a wonderful installer.

for example to install the icecast perl module

you run
$cpan
cpan> install Net::Icecast

it will get the module in question and any dependencies you might have. then it will compile and install them. it has similar facilities for searching and quering package information. what more does the pear installer do?

it's nice that php finally has such a beast. like i said things might have changed in the last year or so. a quick browse through the available packages at pear shows that they still have a long ways to go though.