PHP MySQL Website Programming

Alan Knowles writes "Ever started looking for a PHP script to solve that problem in your company - Managing the passwords, keeping track of equipment, or making information available on the web. Normally after a few hours of hunting, you track down something that looks close to what you want, you download it, get it going, then start digging around the code. At this point, you cringe in fear of two problems, the spaghetti mess that you are about to deploy, the ongoing maintenance nightmare and the horrors of modifying it to fit your needs. Well this book isn't going to solve these issues, but at least if a few more of those budding open source developers read it, the world would be a better place." Read on for the rest of this review; Yes, the book is still available. PHP MySQL Website Programming Problem - Design - Solution author Chris Lea, Mike Buzzard, Jessey White-Cinis, Dilip Thomas pages 504 publisher Apress rating 9 reviewer Alan Knowles ISBN 1861008279 summary Effective learning through the Problem, Design, Solution approach

In brief: This book takes you through designing a PHP website, featuring the usual bundle of generic features, simple content management, adverts, forums and an on-line shop. It's not intended as a definitive codebase of the absolute best design, but fills a big gap between trying to develop PHP with functions and lots of include files, and the full Computer Science bible of Design patterns.

For those people (and there's a lot of them) who have grown from Word macros and Visual Basic, then had a lot of fun learning PHP, this book provides an excellent gentle path towards using classes in PHP and applying them to real world problems. Like a lot of Wrox books, it's jam-packed with code, with a good flow of new information in each chapter.

What I liked

As a programmer who many years ago swore blind that there was no reason for using classes and objects on websites (the equivalent to a misspent youth), this book gives good clear examples on how they can provide advantages over just 'include' and a few functions.

The book is enjoyable to read; it focuses on the step-by-step delivery of a very dynamic website,starting with the basics of designing the file layout and how the files will work together. It then goes into more detail on delivering each feature, provides enough general ideas to help most PHP enthusiasts and budding developers understand the basics and advantages of OOP programming (although there are a few functions thrown in to ease in those not conversant with OOP).

The website that you learn to create (using the Problem - Design - Solution approach) is available for you to see online here.

Although a lot of the code is focused around implementing a reasonably simple set of Patterns, Data Objects and Page execution scripts, there are a few gems in there.

• Utilizing quite a few PEAR classes including the Database abstraction layer, Mail Sending.
• A nice section on the basics of RSS and XML, not to detailed level, but a good warmup for anyone coming from a System Admin or Simple Visual Basic level.

Ok, It's not for everyone. If you've done any Java or C++, this book is going to be a bit below you. Design Patterns are not mentioned directly in the book, although a number are implemented. The book misses out on quite a few important ideas, like templating php sessions in the body, although it does touch on the subject near the end. Given the target audience, of PHP of beginner to intermediate level, it does have a few unusual code styles in places, which hopefully the readers will not over-apply.

What you will learn from this book

• Elements required to build a useful 3-tier web application
• Design and construct an interactive User Interface (UI)
• Provide a CMS environment to manage content securely and extensively
• Create visitor accounts, to register and manage unique site visitors
• Build a simple news management and delivery system
• Create a syndication application
• Generate a sustainable revenue stream from advertising
• Implement an online visitor poll
• Create a fully featured discussion forum
• Build an online shopping cart system with checkout features

Summary While personally this isn't the book for me, as I've learned far too much PHP for my own good, it's the book you wish half the sourceforge PHP project coders would read before starting their project, saving you a wasted download. In the end it's ideally suited to a PHP website development training course, and could almost be the course book. (However, it's better written than most of the school books I remember).

You can purchase PHP MySQL Website Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Why WOULD you use classes and objects?

[FyRE666]

Although I use Java, where OOP is hard to avoid (and I wouldn't want to most of the time), I don't see the need to introduce the performance sapping abstraction of setting up classes and so forth with web scripts.

Let's face it, by the time you've declared you classes, instanced everything a procedural approach would probably have executed and be wating for the next client...

Re:Why WOULD you use classes and objects?

[ebuck]

Well, I can see your point (as I once had it in the past myself) but to have that point you may be missing out on the techniques that (sometimes) favor the class based approach.

You only pay for instantiation (setting up of classes) once, at the time of the class's creation. I have seen many projects fail to keep often used classes around, or worse, design a system that demands the recreation of often used duplicates.

Most of the time this is due to fresh java talent leveraging their accumulated problem solving skills in ways that subtly or overtly casue maintainability or performance issues in Java.

Other times it is for various other pressures on the code (ie. management doesn't care, but wants it out NOW!)

My point is that there may be two markets of web code. That which is suitable for the quick demo, test, one-off, which doesn't need to scale or handle monstrous punishment, and that which is written from the outset with scalability, maintainability, etc... in mind. Rarely will a site fall completely into one of these endpoints of the spectrum, but you get the idea.

Code for a quick knock-off requires a language with a quick return on investment. This is why there are still people using sh/csh/ksh for install scripts, admin routines, etc. Php is not as coarse as these primitive examples, but unless more books talk about scaling PHP and improving code maintainability, PHP will constantly be open to critisim common to nearly all forms of scripted code.

Code on the other end of the spectrum lives in a different environment, and comparing the two is just about as difficult as comparing the wages of "the average worker" in two countries on opposite sides of the world.

SAMS PHP and MySQL - Web Development?

[zhrike]

How does this one compare to the SAMS book?

I used this one to get going, and found it very useful. Does anyone know if the book reviewed here
presents any significant benefits over the book I mentioned?

Don't bother

[larry bagina]

There are 4 authors, and I'm not sure there was even 1 editor. Like many multi-authored books, half the chapters are spent repeating information that will be reworded by the next author. Maybe they could get jobs as slshdot editors? :)

The example code is contrived and ignores a lot of real world problems. Of course, if you're writing a shopping cart of your own, you won't learn anything new here. If you don't know php and want to add some dynamic content to your web pages, it's a good book, though.

Good and bad reasons for OO

[einhverfr]

I tend to use a hybrid approach. There are many things that are fast and easy using proceedural programming, and I would think that probably 90% of the programming I do is proceedural. Many of my prjects are entirely proceedural, and the rest usually have their core written proceedurally.

That being said-- there are several reasons why I might use classes and objects:

1) Complex data types being moved around. I often use them like structs.

2) Sometimes extremely complex and recursive data structures benefit from having functions attached to them. For exmaple if I am generating a PDF from a database query and I want this to be extremely extensible, there is no substitute for OO in its elegence.

3) SOAP integration is FAR easier with OO programming. If your application needs SOAP, I suggest using OO for every SOAP-related object.

4) Sometimes I use objects to hide ideosyncrecies from the program. Usually, the program is not aware that this is an object, however.

Bad things about OO:
1) For most tasks, OO is sort of like slicing a loaf of bread with a table saw. It is unnecessarily complicated and wasteful (performance hit).

To recap, I find that OO is useful with complex data interactions, wrapping non-standard behavior (making PostgreSQL's record set appear forward-only for example), and for SOAP integration. But I wouldn't use it just because someone says its cool ;-)

Re:PHP Design

[telbij]

I have been saying for years now that PHP design needs to be somewhat standardized so that we can all make our mods fit better.

Fit better with what? If you want a standard Web site, there's plenty of content management systems out there with a variety of module interfaces to choose from. If you want hard-core general purpose modules, look no further than PEAR.

If you're suggesting there ought to be something between those 2 then go ahead and start a project, but I think there's plenty of open-source infrastructure out there already.

If you're suggesting that there's a wide variety of PHP crap out there, then I agree wholeheartedly, but unfortunately there is no solution. The easier a language is to get into, the more beginners will release a bunch of crap for it. Your only option is to learn to sort through it.

OOP is waaaay oversold

[Tablizer]

Time for this longtime "OO troll" to step in here. While I think OOP might contribute minor improvements for components with simple, stable interfaces (a relatively thing), it is no magic bullet by any stretch. I have not seen the alleged "proof" in this book, but most other cases of "proof" I have seen had warped reasoning, especially about how things tend to change over time.

The world's patterns of change tend not to be hierarchical nor polymorphic. These "taxonomies" are artificial structures introduced by OO authors, but there is usually no "tree cop" or "polymorphism cop" in the real world that assures that new changes fit the shape of these concepts. Change is more random in my observation than OO proponents assume. Marketers and bosses that ask for new features don't care about the shape of OO when they invent requests. OO books present an artificial view of change patterns, and students take it as gospel. We need more science and less doctrine. To build good, lasting software, one has to first become a student of change. The change patterns I have observed so far do not fit OO for the most part.

OOP Criticism Website

my php project

[pdEo2x5o3bq]

I have a message board system Im currently developing in php. Let me know what you think, and/or if you have any suggestions. thanks. The URL: www.webula.net -Josh PS- support for this project is appreciated. Email me at josh at webula dot net

Re:No, not really

[Lordrashmi]

I should have clarified. I don't think OO is the silver bullet that solves all problems. However, atleast in the software I write, I tend to load one group of data into an object, then call $someObject->getX(). If I called getX() from an include file, it would not know what version of X to get. You could however use getX($id) to fetch the data.

Bottom line, it all comes down to what works for you and how you learn to think. I was struggling with using OO at my new job (They encouraged OO but there was still plenty of procedural) when all of a sudden I had an epiphany (sp?). Now when I think of software (And sadly even real life things) I think of the as interconnected, self contained objects.

This is a debate that will never be settled though and thats part of the fun of talking about it :-)