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

Who needs this?

[Anonymous Coward]

Seriously, a college education in MIS provided everything you need to create a fully scalable, multifacted, fully functional e-commerce portal to create new paradigms of customer interaction.

Re:Who needs this?

[mgrennan]

I've working in MIS for 25 years. I have a high school education and a brain.

In this time I have worked for two PHD's in computer science and both thought I also had a PHD because they had to come to me to find out how things realy work.

Re:Who needs this?

[websaber]

One thing I can assure you this book doesn't teach is how to handle to many connections (Slashdoted). Try clicking on the sample website to see for your self.

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?

[SweetAndSourJesus]

Portable code. It's nice to be able to reuse components.

Ease of use. Once you've got your objects rolled up, just plug em in and go.

Uhm, do I really have to explain the benefits of object oriented programming?

The performance hit is something of an issue, but I think it's going to be resolved with the Zend 2.0 engine in PHP5.

Re:Why WOULD you use classes and objects?

[Lordrashmi]

Using classes and objects makes a project alot easier to maintain. It is nice to know that every time data X is show on the page, it is provided by $someObject->getX()

Unless each bit of data is always only shown once in a system, there is a place for classes and object.

Re:Why WOULD you use classes and objects?

[Anonymous Coward]

That is a good point. Unfortunately, the only reason I would use classes is because they provide variable scoping. PHP is horrible when it comes to variables. You can't explicitely create a new variable within a block (only at the function level), which means you have to global stuff, or spend hours tracking down why some variable is being accidently set in someone else's code. PHP OOP is otherwise poorly designed. Don't get me started on perl, though!

Re:Why WOULD you use classes and objects?

[iabervon]

OOP is great for some things (and web scripts involve some of them, sometimes), but it's terrible for things organized around the ordered production of output (as well as for new functions on old data types, and a number of other things). Java does well because it's used for cases which aren't the ones where OOP sucks. When Java does web scripts, however, it generally uses JSP, which isn't object-oriented at all (other than calling object-oriented code).

OOP is totally useless for the web script itself, which lacks any logical object to orient your programming around, but it can be nice for the code you're reusing from other scripts, where it involves some data structure (although there are also cases where good procedural discipline, like putting all of the headings and such in procedures that can be replaced easily, is also important). Then you don't have to declare the classes the second time, and you start to save time.

Re:Why WOULD you use classes and objects?

[tcopeland]

Right on. It also lets you bolt on an XML-RPC or SOAP interface later on, which is what we've done with GForge.

Tom

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.

Re:Why WOULD you use classes and objects?

[SunBug]

Reusability plays a big factor in why to use an OOP approach. Take a database abstraction layer, you could do something like:

$con = new dbMySQLCon(server params here);
$res = $con->Exec("SELECT * FROM users");
for($i = 0; $i < $res->NumRows(); $i++)
DoSomething($res->Result($i, "field"));

And then later, if you needed to switch to PostgreSQL, you would change one line of code:

$con = new dbPostgreSQLCon(server params here);

Sure, you could write an abstraction layer and rewrite that if you wanted to change the underlying database, but then you wouldn't be able to use multiple databases in the same script.

Well, you could, if you encapsulated everything into an array with attributes ($con["db_type"]="MySQL"), but then you are just reinventing the OOP wheel.

Another advantage is when you have data that needs to be consistently massaged. You can say $obj->GetSomething() and the GetSomething method can massage the whatever before it returns it. You've got one place to change how the somethings look on your entire website.

OOP isn't the magic hammer that the Java people want you to belive it is. Though, when used properly in a mix of procedural and OO programming, maintainability and code clarity goes up dramatically for little extra work.

Re:Why WOULD you use classes and objects?

[telbij]

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

It's already going to be twenty times slower than a custom Apache module in C. Performance is not the hallmark of interpreted scripting languages, development costs are. So if you're looking as whether you use classes or procedural scripts, the deciding factor is not going to be whether it took .01 seconds or .02 seconds to generate the page.

I don't see the need to introduce the performance sapping abstraction of setting up classes and so forth with web scripts.

Well then you've never built a large Web site with any kind of engineered infrastructure. Sure you can bust out a quick script to mail a form or something trivial like that, but suppose you have 50 forms and you want to keep track of who they mail to in a database, and you have 500 pages for which you want to generate bread crumbs and dynamic menus, then you have 5 designs that you may want to update without changing 50 pages at a time. Well you either better have a REALLY good naming scheme for all your functions, or you could use objects to namespace your functions and provide some kind of method to the madness. You could argue that such systems should be built in a more industrial language, but there is a HUGE niche for rapidly developed web apps with enough engineering to actually be useful for several years. Not all (or even most) complex Web sites have the huge audiences that merit extreme optimization.

Re:Why WOULD you use classes and objects?

[tuffy]

OOP is totally useless for the web script itself, which lacks any logical object to orient your programming around

Eh? Isn't the HTML tag a good logical object to base programming around? By pointing an HTML form input object to a CGI form data object, you could create form objects capable of not only printing themselves (such as <input type=text maxlength=20> from a TextInput object) but also automatically ensuring the submitted form's values are within specified bounds (i.e. cropping off a posted value greater than 20 characters) and that's just for starters. Of course, having *all* of one's HTML tags as objects is likely to pose a huge performance hit, but I've found the technique useful in small doses for encapsulation purposes.

Re:Why WOULD you use classes and objects?

[Webmonger]

I'm working on converting my web site from straight HTML to PHP + XML, to ease the pain of future changes. My thinking is, as long as I preserve all the data I think is important in XML, I should be about to output it however I want. I'm going OO with this.

One object type I have is a "renderer". Its job is to output my data in whichever form I ask.
Here are three different renderers operating on the same data:

Old, new, RSS.

I also have Parser object that uses the Expat PHP interface, objects for news items and links, etc. To me, this form of organization makes sense. It helps me centralize information, and prevents stupid mistakes like putting a news item inside a paragraph. It also supports "programming-by-difference"-- most of the methods in the "old" renderer are also part of the "new" renderer, but wherever I need to, I can change the "new" renderer freely. The RSS renderer, on the other hand, is based on the "blank" renderer, so it defaults to doing nothing. Of course, YMMV.

Re:Why WOULD you use classes and objects?

[mgkimsal2]

It makes more sense to keep variables local to function scope.

If I'm calling a function, I should be explicit about what I'm passing in and what I'm returning. Using GLOBAL in functions should not be done. Can you give me examples of what you'd need to globalize in a function (or method)?

There are a couple times I've had to do that, which pretty much just drove home the fact that the app wasn't architected properly in the first place.

Re:Why WOULD you use classes and objects?

[Evil Grinn]

Reusability plays a big factor in why to use an OOP approach. Take a database abstraction layer, you could do something like:

$con = new dbMySQLCon(server params here);
$res = $con->Exec("SELECT * FROM users");
for($i = 0; $i NumRows(); $i++)
DoSomething($res->Result($i, "field"));

And then later, if you needed to switch to PostgreSQL, you would change one line of code:

$con = new dbPostgreSQLCon(server params here);

I've never used PHP, but I hope that the above does not represent the normal way to connect to a database in PHP.

This is a step or two backwards from almost every other technology. Perl has had DBI or years, for instance.

Well, you could, if you encapsulated everything into an array with attributes ($con["db_type"]="MySQL"), but then you are just reinventing the OOP wheel.

Once again, I'm not familiar with PHP but in almost every language/platform/environment I've ever seen that could access a database at all, this "wheel" is part of the standard library or framework and not something you'd need to (re)invent yourself.

Re:Why WOULD you use classes and objects?

[SisterRay45]

The way in which classes are implemented in PHP makes it very unlikely that you suffer much of a performance hit for using them. We use them at work and from playing around with them they are really just structs with methods attached to them there isn't support for some of the features that you might think would cause performance problems. PHP is not a language you use if you care all that much about performance anyway.

Sometimes its easy to keep track of state in a class and while you can do this without classes by using sessions it sometimes is just easier to express what you want to do in terms of a class.

The things which cause java problems for performance have less to do with its OO nature and more to do with its use of a JIT; which in itself wouldn't be a problem but Sun has not been that interested in performance from what I can tell.

Re:Why WOULD you use classes and objects?

[Lu1g1]

I kind of agree with you. However writing all the classes and other basic stuff takes a lot of time. On the another hand, well writen classes make it easy to maintain and extend your application.

To solve the initial problem - implementing all the required classes when you only need simple functionality - I wrote an code generator. You can try it here: http://titaniclinux.net/daogen/

It generates PHP and Java value objects and DAO classes.

Re:Why WOULD you use classes and objects?

[ajs]

You missed the point of using an OO design model entirely. In fact, if these are the reasons you're using OO methodologies (much less language tools), you should probably stop.
You cite:

• Portable code [...] reuse components -- Beyond the fact that the word "portable" is mis-used here, you're invoking the myth of OO reuse. Far better men (and women) than I have refuted this point, but I'll just summarize by saying that code reuse is not a feature of OO programming. It's a feature of modularity and quality of design. It's also very, very rare outside of library and toolkit design where it's always been, before and after the OO craze.
• Once you've got your objects [...] plug em in -- That's called modularity. Not an OO feature, but a design feature.
• Uhm, do I really have to explain the benefits of object oriented programming? -- No, they're well understood... er, or so I thought...

So what are they?

They're the building-blocks of OO, and the benefit is the flexibility that those building blocks give you. If you're a good programmer who writes procedural code, you'll usually find these features seeping into your programs anyway. Languages with OO features just make it easier to apply them. They are polymorphism (you know how to deal with a "car", so you don't have to read the manual to start up a "compact car"), inheritance (a "Pinto" is a "compact car" with some special differences like its own version of the "react to rear-impact" event) and encapsulation (a "car" has a "dashboard", a complex object with behaviors of its own). IMHO, polymorphism is the most powerful and valuable of these, though many will focus on inheritance, which is deeply tied to polymorphism anyway, so YMMV.

Re:Why WOULD you use classes and objects?

[Tablizer]

Portable code. It's nice to be able to reuse components.

Even many OO fans agree that "OO is not about reuse". The reuse push seems to be falling out of favor as a top selling point of OO. (See: http://www.c2.com/cgi/wiki?ReuseHasFailed, generally a pro-OO group.)

Ease of use. Once you've got your objects rolled up, just plug em in and go.

I used to use FORTRAN graphics components, and I do not see any significant differences between them and OO components. Perhaps you were just a shitty procedural programmer (I can't tell without seeing what you are comparing. Note that I am NOT promoting the FORTRAN lang here.)

Re:Why WOULD you use classes and objects?

[1110110001]

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...
You could preload your code (and some kind of pre-compile) with a php script cache software like PHPA. BTW in PHP4 an object ist like an array with a table of its own functions-scope (its methods). Thus oop in PHP4 is pretty fast. PHP5 has a little bit more overhead (an object is a handle refering to the object table) but with many advantages and if it's too slow use something like phpa again.
b4n

Re:Why WOULD you use classes and objects?

[mosch]

your 'new' renderer crashes safari beautifully.

Re:Why WOULD you use classes and objects?

[Tablizer]

And then later, if you needed to switch to PostgreSQL, you would change one line of code:
$con = new dbPostgreSQLCon(server params here);
Sure, you could write an abstraction layer and rewrite that if you wanted to change the underlying database, but then you wouldn't be able to use multiple databases in the same script.

I don't think you need OO for that. You could use *named parameters*, but unfortunately, PHP does not provide those. I miss named parameters.

$con = DBconnect(); // default driver

$con = DBconnect(driver="oracle");

Re:Why WOULD you use classes and objects?

[Tablizer]

IMO, code generation is a sign that your language or techniques don't support a high-enough abstraction level or an expressive enough language.

In some cases perhaps it can be justified for speed, but otherwise your app should use the meta-data *directly* rather than have it turned into code, because that way you have one less layer. Generated code is usually bloated compared to the meta-data that was used to generated it. IOW, it goes from high-factoring to lower factoring.

Re:Why WOULD you use classes and objects?

[budgenator]

I'm not a JAVA programmer, in fact I keep thinking that I don't understand OOPs at all. But GCJ seems like it would be the ticket to boost performance up a couple notches

Re:Why WOULD you use classes and objects?

[acostin]

Hi, I have seen your site, and it seems that Komplete Lite could be able to help you, as it already has:

• XSL/XSL core - generate dynamic XML trees from database or use your own trees
• Separation of concerns (MVC - from Krysalis
• Powerful content management (manage structure and content visually)
• Skins (templates) - just write your own XSLs and you have a new look and feel for your site.
• RSS automatic generation and importing
• Nuggets
• Lots of other goodies

Download Komplete Lite from it's homepage. It requires a PHP 4.3.1 with domxml, domxsl and mbstring, but I assure you it worth to take a look.

Re:Why WOULD you use classes and objects?

[Tablizer]

Well you either better have a REALLY good naming scheme for all your functions, or you could use objects to namespace your functions and provide some kind of method to the madness.

Could you elaborate on this please? Often times I use a database to keep track of the menus, scripts, and events to execute. I can then use the DB's query features to search, sort, filter, and group my view of these items just about any way I please. It is harder to do that with classes, as their shape and relationships are more or less hard-wired into code.

Large OO projects are too similar to the "navigational databases" of the 1960's. OO is trying to resurrect a dead horse in new clothing IMO.

Re:Why WOULD you use classes and objects?

[Anonymous Coward]

Oh no, Tabalizer has joined the OO debate... It will never stop *g*

Re:Why WOULD you use classes and objects?

[Chewie]

Unfortunately, in PHP4 (at least, not sure about 5) the native DB connection functions are named by the database they connect to. So, you have a function called mysql_fetch_array, another one (for PgSQL) called pg_fetch_array, and so on. That's why there is the PEAR DB database abstraction layer and ADODB (another one, this time with an ADO-style syntax). That's right, natively it's just that ugly. Does anyone know if they've changed it in 5?

Re:Why WOULD you use classes and objects?

[Webmonger]

Then use a better browser :-). Seriously, no matter how ill-formed a web site's HTML or CSS is, it should not crash a browser. IE and Mozilla render it just fine.

I just made it valid XHTML Transitional 1.0, but it probably still crashes Safari. Ah well. I'll have to snag Opera before I go live.

Re:Why WOULD you use classes and objects?

[Webmonger]

Hey, it's my wheel, and I'll reinvent it if I want to! (It's my project for learning PHP.)

Re:Why WOULD you use classes and objects?

[kp833]

Well this has been going on for ages now. Quick, dirty code which gets the job done in time Vs portable, object oriented and extensible code which will take for ever to build ( ya, i know one good programmer who knows his/her in OO programming can write OO code even with time constraints but lets face it how many people really understand OO programming.. I have done enough OO programming to make this statement) Any way I think the book better serves for "quick and dirty programming". If you want to build php application which work (at least to some extent) and get the job done real quick and if you have some programming experience... then go for it.. for beginners who what to learn php.. why do you want to learn php anyway? if you dont know the answer to this then you dont need any book.

Re:Why WOULD you use classes and objects?

[Anonymous Coward]

Oh no, Tabalizer has joined the OO debate... It will never stop *g*

Slashdot should ban discussion of sex, politics, religion, and OO

BTW, does Saddam use OO?

Re:Why WOULD you use classes and objects?

[Rewd]

Sessions are extremely useful.

I store a lot of info about the current user and commonly-used site configuration variables in a session object variable, which is obviously global.

Having such commonly-used data available as a global is a lot faster than having to query the database every time just to do something like print the user's name at the bottom of each page, or check their security level.

Re:Why WOULD you use classes and objects?

[mosch]

you're absolutely right that it shouldn't crash the browser. that being said, it still crashes safari (and probably konq).

Re:Why WOULD you use classes and objects?

[Webmonger]

I downloaded konq and opera, and both of them were stable, although the layout looked bad. Safari isn't really an option for me,

struck!

[Dri]

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

The review exerpt really struck me. That's what I do alldays. Maybe I should consider reading this book. doh!

Sounds familiar? :-)

[tcr]

Build a simple news management and delivery system

Generate a sustainable revenue stream from advertising

Implement an online visitor poll

Create a fully featured discussion forum

?????

Profit!!

PHP Design

[liveD ehT]

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. What I would like to eventually be able to do is have a framework opensource for a community/news-driven website that quickly figured out my needs, and my customer's needs, with security as a front-running concern. (ie: a way to really mix up the vars/dbvars and such so that it's harder to pry it open)

The problem is that with security, the very best possible way to keep your site secure is to a) purify incoming data and b) keep your source to yourself unless you want people to let you know where the bugs/holes are. I know the open source community is really good and has it's place, but when it comes right down to it, if you fully customize your PHP, then it's more secure because there aren't a bunch of script kiddies looking for ways to hack you on security forums (a la PHPBB script attacks). The good thing about PHP in the open source sense is that you can read it and understand how it works. I don't recommend using any custom packages because there is risk involved that your doing so is going to attract attention from script kiddies. The best thing you could do is learn PHP by the open source examples (run phpbb and read it, run smarty and read it - understand it) but then create your own base, and add your own layers to it.

Re:PHP Design

[Mr Bill]

The problem is that with security, the very best possible way to keep your site secure is to a) purify incoming data and b) keep your source to yourself unless you want people to let you know where the bugs/holes are.

The problem with this philosophy is that it allow you to be sloppy with your code. You might start out with great intentions of keeping the code clean, but without the fear of ridicule associated with peer review, you will start to slip to catch that deadline.

Knowing other people are going to see the code is the best way to keep a programmer in line. An artist is not going to show all the crap they come up with to the world. They pick their best work and share it because they are proud of it.

Now if only I could adhere to this philosophy myself...

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.

Re:PHP Design

[Anonymous Coward]

What you're looking for is perl.

Re:PHP Design

[MattW]

I think you've missed the point. Security through obscurity doesn't work because it is possible to find holes -- especially php/mysql website holes -- without access to the source. If your code is auditable, then those holes become very public knowledge -- and you can fix them. If you do not, it's much more likely that the person who took the time to find the hole will not share it, and it will be exploited silently.

So it becomes a question of what you'd prefer. A public change to see the error pointed out and to fix it, or a private use of your error for nefarious purposes.

Is it just me, or ...

[siliconwafer]

have we had a ton of PHP/MySQL book reviews lately?

Hold it right there!

[Anonymous Coward]

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

What do you mean, "fun learning PHP?" I'm a Microsoft guy and there's only one way for me... the Microsoft way. Buddy, I think you should be talking about ASP and VBScript, the nectar of the gods.

I started my career hacking up Word macros, then slowly picked up Visual Basic. I can't wait to see what Microsoft has in store for me next. Maybe Visual C#? Hmmm... I won't touch anything non-Microsoft with a ten foot pole, because Microsoft always comes out with the best cool shit and I'm a big fan.

I don't know why you people can't just accept Microsoft and all its products and move on with life.

Re:Hold it right there!

[alman]

I agree.
Microsoft pays my bills.
And since I've pulled out all my hair, I don't have to worry about hair cuts, I get to spend that 1/2 hour/month reading MSDN magazine!
Also, they helped provide me with this nice padded room, the walls are soft and squishy. Really nice.

Re:Hold it right there!

[Anonymous Coward]

Damn, I'm confused...

Are you being sarcastic, or serious?
If you're serious, ARE YOU NUTS???
I'm sorry, but this is flamebait waiting to happen.

Re:Hold it right there!

[Anonymous Coward]

This, friends, is why most dorks are lonely virgins.

Re:Hold it right there!

[Eneff]

Bravo!

You deserved a Score:5, Troll for that one!

Re:Hold it right there!

[Anonymous Coward]

...Microsoft always comes out with the best cool shit and I'm a big fan.

And when the shit hits the... well, you know.

darn it

[Anonymous Coward]

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

I though this was the answer to my prears...

Re:darn it

[Anonymous Coward]

This book may be the answer to your prayers.

Two Problems?

[Anonymous Coward]

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.

There are three types of people in the world: those who can count, and those who can't.

Re:Two Problems?

[HerbieStone]

There are three types of people in the world: those who can count, and those who can't.

Ahhh, reminds me of the Monty Python sketch.

Ximinez: Nobody expects the Spanish Inquisition. Our chief weapon is surprise ... surprise and fear ... fear and surprise ... our two weapons are fear and surprise ... and ruthless efficiency. Our three weapons are fear and surprise and ruthless efficiency and an almost fanatical devotion to the Pope ... Our four ... no ... amongst our weapons ... amongst our weaponry are such elements as fear, surprise .. I'll come in again. (exit and exeunt)
Reg: I didn't expect a kind of Spanish Inquisition.
Jarring chord. They burst in
Ximinez: Nobody expects the Spanish Inquisition. Amongst our weaponry are such diverse elements as fear, surprise, ruthless efficiency, and an almost fanatical devotion to the Pope, and nice red uniforms --

Re:Two Problems?

[daeley]

Actually I think he/she/it might be saying one cringes in fear of two (unspecified) problems, as well as cringing at a mess, a nightmare, and some horrors. So there are at the very least five items at which one cringes. No word on what those Two Problems That Must Not Be Named are, but they must be doozies. ;)

Re:Two Problems?

[Slime-dogg]

I read that sentance, and I was looking for the second thing you'd cringe from. Spaghetti Code is a maintenance nightmare, and modifying it is horrific.

What was the second point?

Re:Two Problems?

[GlamdringLFO]

Actually, there are 10 kinds of people in the world. Those who can count in binary...

Classes?

[symbolic]

As a programmer who many years ago swore blind that there was no reason for using classes and objects on website

I put together a javascript/php-based web aministration tool for a web site, that without classes, would have been a nightmare. Classes aren't necessary in every case, but when the problem space reaches a certain level of complexity, NOT using them can be a very poor choice. But then, after one decides that classes would be appropriate, using them effectively is a whole different ball game.

Re:Classes?

[siliconwafer]

I've found classes to be very useful when bringing data out of a database. For example, if you have a table in your DB called "Users", you can simply create a PHP class called "User", do a "select * from Users where Userid=blah", and have your user object ready to go. Of course, PHP also has mysql_fetch_object and such now as well.

Re:Classes?

[Chazmyrr]

Depends on how long you want to persist that data. If all you need to do is display, what is the benefit from loading it into a class rather than just accessing fields in the recordset? Even if you do need to persist, what benefit do you gain from caching the object as opposed to caching the recordset? Keep in mind the possibility of using client-side cursors or disconnected recordsets.

If you need to perform updates, putting your business logic in an object, rather than a stored procedure, can have its own problems. If you don't use a stored procedure, you compromise data integrity and security at the database level. If you do, why do you need the object? If the operation is part of a transaction that includes calls to other systems, you might be able to make a case. Although, I would prefer to provide the stored procedure with a means of making that call.

OOP Speeds Development

[chrisseaton]

I think OOP speeds development (it certainly speeds changing and expanding existing code) so you could say that you "by the time you've written everything using a procedural approach you probably have finished and be wating for the next client with OOP..."

People seem to be more concernded with development speed on the web (most web languages are interpreted, which speeds development at a massive expense of runtime speed) so OOP is natural for web languages.

build great code like this

[DrSkwid]

/></td>

in 24 hours

Re:build great code like this

[Anonymous Coward]

Did that mean anything?

Re:build great code like this

[Dthoma]

The parent may have been joking, but they make a good point about one of PHP's weaknesses. Because PHP can just spew out HTML at random points using echo or print you can unintentionally write strings of HTML, 400, 500, 600 characters long without a newline. That sucks.

Actually, it's not totally PHP's fault. It's pretty obvious that the echo statement doesn't actually output a newline each time you use it. This is very useful, but it's a problem when you're using it as an Apache module or CGI scripting language since you can make ridiculously long lines of HTML and other text without realising because you forgot to insert a newline at the end of each echo statement.

I'm still not sure whether this phenomenon is more the fault of the language or the programmer.

Re:build great code like this

[GutBomb]

um... "\n" anyone?

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?

Re:SAMS PHP and MySQL - Web Development?

[Anonymous Coward]

All I know is dont ever purchase MySQL/PHP Database Applications by Jay Greenspan and Bulger . I have never seen a book have sooo many typos and buggy examples. The only good thing about this book is that its super easy to understand for those who are getting standard in any type of development. Their MySQL Database examples were not that good either.

See also...

[gmuslera]

... Web Database Applications with PHP and MySQL, from O'Reilly. It not have the same focus as this book, but will give also a lot of useful concepts.

Object Oriented Classes

[DarkHelmet]

I do use PHP classes in some of the code that I create. I do not use it for everything I do, but there are a couple things that I find where it makes my life easier.

My biggest gripe about PHP in regards to classes is that you CANNOT create a deconstructor function in your classes. Their reasoning is that they cannot make it where you know which order the deconstructors will be called.

Instead, the workaround is to create a function to handle the script ending using register_shutdown_function(). This is incredibly annoying, and for the most part I don't even use it. It just forces me to write a function called ClosePage or something to that effect.

I like classes, and it's worth at least looking into using them on your pages (at least for code you'll be constantly reusing). For those of you who are concerned about speed in using classes, get PHPA.

Hopefully PHP5 will fix some of the issues in using classes in this language. But until then, be hesitant.

Re:Object Oriented Classes

[Ponty]

My biggest bother is that function overloading isn't supported in a stable fashion. Half the times I'm inclined to use objects, it's because of overloaded constructors.

Re:Object Oriented Classes

[Anonymous Coward]

You should look into what's going into PHP5. deconstructors are just one of many things. PHP5 dramatically improves PHP's OO set. OO in PHP is now not just a hack, but actually designed to work well.

I believe the functions to do this are __deconstructor() and now they will implement __constructor() as well.

Just do a search on google for PHP5 overview, and you should get quite a few links.

PHP, JSP, ASP ???

[Anonymous Coward]

Yes, this is flamebait. Which is best? I don't know and would appreciate any insights.

buy it cheaper at amazon

[gnurb]

It's $34.99 at amazon with free shipping. ($39.99 at bn)

There's also a $5 off $35 coupon floating around...

Re:buy it cheaper at amazon

[Anonymous Coward]

i'll buy it cheaper at amazon when those bastards give me the $900 back I lost because of their incompetence.

Yes, in fact I am a Grammar Nazi

[Anonymous Coward]

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

Ever started a sentence.

. . . and then forgot to end it?

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.

Re:Don't bother

[Anonymous Coward]

There are 4 authors, and I'm not sure there was even 1 editor.

Well, there definitely aren't any editors working for Wrox any more, as they've all been laid off - the parent company went bankrupt on March 14, 2003. I believe that's what the "Yes, the book is still available" comment at the end of the review is referring to.

Question

[DumbWhiteGuy777]

"Ok, It's not for everyone. If you've done any Java or C++, this book is going to be a bit below you"

Does this make me 1337?

Re:Sounds familiar? :-)

[red_dragon]

To those familiar with it, #5 obviously is:

• Sell it all to Andover.

Not just a PHP problem

[phorm]

With understanding that this article is a reference to a PHP book (and the more books to educate the undereducated... the better), the problem with shite code samples extends far beyond PHP.

Part of the reason it applies so readily to this language, however, is the conceived ease-of-use. A lot of newbie users swap to PHP, pick up some bad samples, combine with existing bad habits they never grow out of, and eventually consider themselves "knowledgable" just to to long-term use. However, experience in duration != experience in education (standardization, etc).

To shift the blame from PHP, I've been working on attempting to integrate a 3rd-party web-based system (Perl-base) into my place of work. At first, I looked at the code and estimated that I could do it relatively easily. What I neglected to realize, is that while some of the coding was done reasonably well... this seems to be a multi-person project and other sections are nightmarishly and un-necessarily complex.

We need an article on "signs that you're working with bad code." So far I've found...

• Poor indentation
• Low commentation (for godsakes, use # and throw in at least a few words every now and then
• Really ambiguous variable names: $x1, $x2, $blah, $stuff
• Odd information passing: As a delimited string...which is interpreted differently based on certain conditions (contents of string may vary)

Maybe we need a "warning signs" section. Anyone got one?

Re:Not just a PHP problem

[Anonymous Coward]

I'd be surprised if this hasn't been on here at least once...

How To Write Unmaintainable Code

Re:Not just a PHP problem

[thinkninja]

Low commentation (for godsakes, use # and throw in at least a few words every now and then

Offtopic, but, FYI, use of perl/shell style comments is discouraged by PEAR. I think if PEAR standards were more visible, we'd see less freakish code. Although, why they choose to use Allman over 1tbs is beyond me (-:

Re:Not just a PHP problem

[phorm]

Actually, I was thinking in Perl'ese. I guess in PHP it would be the ol' double-slashed comments

Re:Not just a PHP problem

[pi_rules]

I agree, every beginner book on a subject should have examples of the shit people will do and think it's okay when it's not. I'd like to add to your list though:

• Sections, or lines, of commented out code that remain over time. If you feel the non-working code should serve as an example, comment why it's commented out.
  
• Code that breaks the 60-lines-per-function rule. This is varying rule, as the more complex the code is the shorter the function should be, and the less complex it is the longer it can be. Nothing wrong with 120 lines in a case statement, as long as each block is only a couple of lines long.
  
• Code that breaks the 3-indents rule. This one and the previous I've garnered from the Linux coding standard recomendations. They're good rules if you ask me.
  
• Code that includes code that slaps things into the same namespace. This is inexcusable, unless you're pulling in constants. If there's logic required to obtain a commonly used parameter then put it in a function, include that function set, and call that function and assign it to a variable declared in the scope it will be used in.
  
• Code that includes other pages, does some logic, and includes more pages. Sorry, not acceptable. It shows poor design and lack of initial thought.
  
  Just my two cents. I see this a lot on projects and they're dead ringers that what I'm about to embark into is just a sheer mess.

Re:buy it cheaper at amazon (you sure?)

[Anonymous Coward]

I found the same book at $27.99... :-)
There seems to be a few other places with free shipping..

Book even cheeper..

Re:Ebooks

[Anonymous Coward]

Check out freenet, eDonkey, or DirrectConnect.

It has been -390 seconds since you last had forbidden thoughts about cowboykneel

Re:PHP, JSP, ASP ???

[son_of_asdf]

JSP I know nothing of, so I will not comment on it here. RE: PHP and ASP, unless you want to spend a huge amount of money that doesn't really have to be spent and lock yourself into the Microsoft Way, avoid ASP at all costs. PHP in combination with one of many fine open source databases (I'm fond of MYSQL, but these are other good options out there) is free, non-proprietary, and easy to work with. All you need is an old Linux box, a text editor (emacs for me, but pick your own flavor), and a week's worth of evenings to study and you'll be ready to rock, even if you're like me and are not an uberhacker by any stretch of the imagination. For MYSQL, a copy of PHPMyAdmin is useful too, as it makes administering your database a LOT easier.

The Superiority of PHP over Perl

[Anonymous Coward]

Recently I've had a chance to do some web design with PHP. Previously I'd used Perl because I'd heard from many people that Perl was the end all and be all of scripting languages for the web. Imagine my suprise to discover that PHP was vastly superior! I know this is a bold statement, but I have solid arguements to support it.

Before I begin, let me just clarify something. I'm not arguing that PHP is better than Perl in all cases. There is certainly still a use for Perl. Also, PHP isn't perfect but it does manage to fix many of the shortcomings I've had with Perl. Here are a few of the things I've noticed about PHP. Finally, I'm not the most talented Perl programmer out there. I generally prefer to use the vastly superior Python, but can use Perl if I have to.

• Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.
• The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.
• Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.
• Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point. I'm sure there are cases where Perl is equal to PHP, but I can't think of any at the moment.
• Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires that much rewriting.
• Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library of any kind.
• Data Structures. Under PHP you can create any type of datastructure you need: Linked lists, binary trees, hash tables, queues, inverse Reiser-biased recursion trees, etc. Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used. Because of this, PHP can support complex data structures.

Again this is just my experience. I don't mean to offend any Perl coders because Perl was an excellent language. However, in certain cases it may behoove one to write the back end in PHP instead of Perl.

Re:The Superiority of PHP over Perl

[czth]

Nice troll. Very cute. I guess the reason why you haven't been flamed yet is that the Perl programmers can see it's a troll and the PHP users don't care either way.

czth

Re:The Superiority of PHP over Perl

[taperkat]

I find both Perl and PHP to have their own various uses. When I was a programmer for a NCAA university's admissions website I was given a rather large thick book on Perl and told to learn. I did, it took about 2 days, and it was really easy - at least, to me, as I was an 18 year old college girl that lost all care about computer languages after taking a C class (hah)....

I've been reading more about php lately as I'm thinking about making a new website, and it seems as easy, I just haven't tried it yet. Why? I guess it's because I'm LAZY, but more because there are *so many* sites that tell you how to do things. Um, it's hard for me to decide what *type* of php to start out with. Standardization is a Good Thing (tm).

Open source doesn't need a book to be better

[damm0]

but at least if a few more of those budding open source developers read it, the world would be a better place

I take exception to this. Open source flourishes at all levels; the inexperienced, the intermediate, and certainly at the expert level. In fact, it is the progression of people from distributing code to distributing useful code that makes open source what it is.

The day you can't download garbage code is the day open source dies.

Re:Open source doesn't need a book to be better

[Tablizer]

The day you can't download garbage code is the day open source dies.

I think I understand what you are getting at, but this is *not* a slogan I would wave around very often :-)

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:Good and bad reasons for OO

[Tablizer]

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.

I am curious as to why OO allegedly makes this easier. Could you by chance provide more details? Thanx

SOAP integration is FAR easier with OO programming.

Not surprising since SOAP is based on the OO paradigm. It is a matter of talking the same (or similar) language (paradigm). Whether SOAP is the best info sharing protocol is another matter.

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

I prefer to use relational tables for such. That way I don't have to re-invent searching, sorting, filtering, joining, querying, etc. from scratch. Sometimes, however, vendors don't support temporary working tables or temp views very well.

Re:Good and bad reasons for OO

[einhverfr]

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.

I am curious as to why OO allegedly makes this easier. Could you by chance provide more details? Thanx

The idea was to generate a reporting engine which created a PDF complete with sections, etc. and fill things in at runtime. The report definitions would be stored in disk-based files and data in the RDBMS. I created classes which had as their members arrays of other classes (sort of hybrid to structural programming). I could then recurse functions down the object model. The report engine in Hermes contains the code for this... See my sig for more info.

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

I prefer to use relational tables for such. That way I don't have to re-invent searching, sorting, filtering, joining, querying, etc. from scratch. Sometimes, however, vendors don't support temporary working tables or temp views very well.

Those work with some things as well, but if you want performance, which would you prefer when you need to parse a timestamp? Would you prefer to insert the information into a temporary table in the database, and then query that table? Or just directly pass it back to the calling proceedure? Assume we need to know the month, day, year, hour, minute, and second of the timestamp.

When I started writing HERMES, I did everything in a proceedural way. The main application server, authentication modules, etc. are entirely proceedural except where I have to, say, make the PostgreSQL result resource appear to the application to be forward only. As I got into the library model, I started writing OO libraries for things like calendars, etc. due to the complexity of the data being passed around. Now I am rewriting the applications running under the app server to be OO so I can support SOAP. This will allow a presentation-independent middleware in the best way possible.

Re:Good and bad reasons for OO

[Tablizer]

The idea was to generate a reporting engine which created a PDF complete with sections, etc.

Aren't there already plenty of report generation engines out there? It does not seem like something that one should have to reinvent from scratch.

Those work with some things as well, but if you want performance...

I have seen some quick database engines. But, I would rather focus on good software engineering rather than speed.

when you need to parse a timestamp? Would you prefer to insert the information into a temporary table in the database, and then query that table? Or just directly pass it back to the calling proceedure? Assume we need to know the month, day, year, hour, minute, and second of the timestamp.

If it is complex, then I perhaps would put it into a table(s). If it is fairly simple, then perhaps I would just put it into an associative array: $timeThing['month'], $timeThing['day'], etc.

to be OO so I can support SOAP. This will allow a presentation-independent middleware in the best way possible.

Well, I am skeptical that it is the best possible way.

BTW, www.compiere.org is also an ERP, CRM tool that you might want to take a look at. (Their documentation needs some work IMO.)

Re:Good and bad reasons for OO

[einhverfr]

Aren't there already plenty of report generation engines out there? It does not seem like something that one should have to reinvent from scratch.

I looked at a few but they didn't seen to be what I was looking for. Not extensible enough, or not Free as in GPL (the program was released under GPL) or not easily integrated with a PHP application.


I have seen some quick database engines. But, I would rather focus on good software engineering rather than speed.

When I wrote HERMES, the common parts of the program, those that get run on every page hit, are written proceedurally. They are kept simple, and extensible with plugins for different forms of authentication and database managers. Well with one exception-- I wrap the PostgreSQL record set in an object so I can hide the fact that it si not forward only from the application. I start working with objects when I get into the business logic of the application or libraries (the application server has a library model).


If it is complex, then I perhaps would put it into a table(s). If it is fairly simple, then perhaps I would just put it into an associative array: $timeThing['month'], $timeThing['day'], etc.

Fair enough. That is an acceptible way of doing things too. I will leave that one up to preference. I can see some advantages of doing things your way, and I can see some advantages of doing things my way. In the end, I would likel y end up with somehting that looked like OO using hash tables and variable functions.

Re:Good and bad reasons for OO

[Tablizer]

In the end, I would likel y end up with somehting that looked like OO using hash tables and variable functions.

I find that algorithms often tend not to stay one-to-one with such data structures. They tend to drift apart, or at least are shaped by different forces. OO fans and I just seem to have a different perception of longer-term code change patterns.

Anyhow, if you do go the route of "putting code in structures", LISP has been doing this for a long time because it blurs the distinction between code and data. I hardly credit OO with inventing it. "Re-discover" might be a better description. C, Pascal, and Fortran-influenced languages are indeed not very good at it, and maybe this is what has given some push toward OO for those with limited exposure to other techniques.

PHP frameworks

[tetranz]

There are several promising PHP frameworks in development.

Ports of Struts
PHP.MVC
Phrame

And ezPublish 3 which is primarily a CMS but can also be used as a general purpose framework.

IMHO for one of these to really take off (like Struts) is what professional PHP development needs.

Re:PHP frameworks

[acostin]

There is also Krysalis for XML/XSL application development (approach to PHP/MVC with the cocoon approach)

And KompleteLite as a GPL CMS - Komplete Lite

We have succesfully created very powerful applications that are *very* easy to maintaing thanks to the separation of concerns (www.mcti.ro, others)

Re:PHP frameworks

[wulffi]

If anybody has expirience with PHP.MVC or Phrame please elaborate on strength and weaknesses of the two...

Please :)

In other words

[L7_]

How to develop phpNuke!

MIS = all you need to build ecommerce site? NOT.

[john bigbootay]

Yeah, I work with a bunch of people with college degrees in MIS. Hmmm, let's see, we've managed to build 3 f**ked commerce applications in 4 years. I think the key ingredients you're looking for is EXPERIENCE and HUMILITY.

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

Re:OOP is waaaay oversold

[Anonymous Coward]

Ah yes, the abstraction is too complex for your small chimpanzee mind to comprehend, so you attack it. Typical.

Re:OOP is waaaay oversold

[Tablizer]

Ah yes, the abstraction is too complex for your small chimpanzee mind to comprehend, so you attack it. Typical.

No no no. I did not reject abstraction, per se, just OO's *brand* of it. Personally I think OO fans don't get relational's abstraction ability/power. But if I said that, it would start a big fat my-paradigm-is-better-than-yours flame war again, so I won't say it :-)

PHP is great! I wouldn't know!

[kevlar]

I've spent on the order of tens of hours just trying to get PHP, MySQL and Apache to play friendly together with no success. I've decided that when someone creates a PHP, MySQL, Apache integrated distribution, then I'll return to trying it out. Until then, I'll stick to Apache + Perl or Tomcat.... It makes building a KnowledgeBase app much more difficult though!

Re:PHP is great! I wouldn't know!

[Cedric C. Girouard]

I've spent on the order of tens of hours just trying to get PHP, MySQL and Apache to play friendly together with no success. I've decided that when someone creates a PHP, MySQL, Apache integrated distribution, then I'll return to trying it out. Until then, I'll stick to Apache + Perl or Tomcat.... It makes building a KnowledgeBase app much more difficult though!

Give a try to ApacheToolbox ... It's most likely what you've been looking for.

Re:PHP is great! I wouldn't know!

[ErikZ]

Under which OS?
I was able to get things working pretty quickly under Windows. It was only when I had to upgrade to Apache 2.x to use some features that were still in beta, did I have any problems.

(shrug) That what you get when you start using non-stable releases.

Re:PHP is great! I wouldn't know!

[gid]

I just set up a debian box the other day with this.

apt-get install apache php4 php4-cgi mysql-server

Then uncomment the necessary lines in /etc/apache/httpd.conf to turn on the php modules. (just search for php and uncomment the lines having to do with php4), then "/etc/init.d/apache restart" and then yer off. You may have to do a little magic with php to load the mysql modules as well, I'm not sure, I kinda forget what all I ended up doing.

This is just with Debian though, I believe there's probably a version of RedHat/Mandrake that has support out of the box, if you're allergic to reading manuals...

Re:PHP is great! I wouldn't know!

[kevlar]

Under Windows I'm sure its very simple because they don't distribute the files across 5000 directories. Under Linux its a bit more difficult. I'm just wondering why nobody has created a tool or standard installer for the set.

Re:OOP is waaaay oversold (correction)

[Tablizer]

Correction: "(a relatively thing)" should be "(a relatively rare thing)"

Me too

[Anonymous Coward]

I second that!

Specifically, can anyone compare the design paradigms presented in the books? Is one better? Why?

Same Cut-and-Paste troll as usual

[androse]

This post is a cut-and-paste job, that has been cut, and pasted, and re-cut, and pasted again, and again and again.

See for yourself and please mod down this stupidity.

Repeat troll

[skillet-thief]

I think this guy has a Perl script that automatically posts the same troll each time a php related story comes up. This is at least the third time I've seen this exact same text. At least it is posted as AC this time, usually it is posted by egg_troll or something like that.

The astonishing thing is that it continues to work!

Re:Repeat troll

[Anonymous Coward]

think this guy has a Perl script that automatically posts the same troll

Uh, that would be a php script, for the aforementioned reasons..

Re:Repeat troll

[Anonymous Coward]

Too hard to do in PHP...

Fusebox with PHP

[DeltaOne18]

One way to help structure your PHP application would be to use Fusebox, an open standard that encourages separation of logic from data (from a DB for example) and presentation (HTML).

I have used Fusebox with several Cold Fusion applications and have that it with FuseDoc are a great combination for creating a webapps in a standard fashion. It allows new developers who are familar with the Fusebox structure to pick up on your design quickly and implement their assigned pieces in a more reusable manner. Here is a good tutorial on Fusebox with PHP. This site is another great Fusebox with PHP resource.

A ColdFusion, Java, and PHP developer's weblog might also be helpful. (Disclaimer this is my weblog! :)

Re:OOP is waaaay oversold (here, here!)

[__aanonl8035]

I want to pipe in and second this view. A big gripe of mine is how arbitrary OO, classes can be on how they are organized. It feels like "another level" of abstraction based upon what the programmer felt constituted an object at the time. I have yet to find an OO PHP application that could not be just as easily implemented with includes, functions, and arrays.

MOD PARENT DOWN

[Anonymous Coward]

Damnit, I don't know which is worse. Trolls or incompetent moderators.

Re:OOP is waaaay oversold (here, here!)

[Tablizer]

A big gripe of mine is how arbitrary OO, classes can be on how they are organized. It feels like "another level" of abstraction based upon what the programmer felt constituted an object at the time.

Amen! One of the techniques I try to apply is "virtual abstraction" (AKA "local abstraction", "temporary abstraction", "ad-hoc abstraction) using relational queries and other techniques. Philosophers have generally concluded that there is no such thing as universal (global) taxonomies and abstractions. Too many OO designs *do* assume that their global abstraction is appropriate. One abstraction does not fit all.

Too many global variables are a bad thing, most would agree. Similarly, global abstractions and taxonomies are often a poor design for related reasons.

running gag..

[s_n]

ouch, I've been hit by a reference - again!

it's not funny. I spent hours today because of PHPs whimpy OO implementation.

Shopping cart is a terrible example

[MemeRot]

Checked out the shopping cart feature first, since I've coded a ton of shopping carts.

TERRIBLE!
I type in 9999999 (ad infinitum) in the quantity field and hit update.

My quantity is mysteriously changed to 147483647. I'm just guessing that's the limit of signed ints on that server. No error message was displayed. Since the size of the field that displays the quantity box is 3, all you see is '214'. An end user of an e-comm site doesn't care what's behind the scenes, they care that the inputs/outputs make sense. This doesn't. The reviewer talked about Design Patterns. Who cares? On the web the first rule you need to follow to have a reliable application is 'Validate user data'. Do that obsessively and you'll probably be ok even if your back end isn't too slick. Fail to do that and you are sunk, no matter how efficient your code is.

Then just to be sure I wasn't being too harsh, I ordered -3 of another movie. Works fine. So you can order three of one movie, -3 of another, and get them for free. Sorry.... a shopping cart without data validation (tedious as it is) isn't a shopping cart.

I hit continue and am told I need to have an account first. I sign up for one. First thing - I'm prompted for my login. Grrr... pet peeve - maintain this in the session please. Then I'm not redirected back to the cart. Oops... lost sale there. So I continue.... lovely, I'm informed that "Error_ Your shipping info is not valid." Man... insulting too. I hate apps that set a user up to fail.... and this does. I update my shipping address as prompted... and nothing happens, I don't go back to the flow of purchasing. Yikes, another lost sale. Even on the last step, my -19.99 order is accepted with no problems.

I know the shopping cart is being offered as an example only.... but c'mon, it should be a workable example. I am looking to learn PHP, but think I'll look elsewhere.

Re:Shopping cart is a terrible example

[Anonymous Coward]

Though, on the positive side, one could hope that lots of people buy this book and program just like the examples.

That way, we'll have a plethora of online merchants where we can get things using special "quantity discounts". :)

Though, if I order -3 DVDs and it takes it ... does that mean I need to send them 3 DVDs?

Re:Shopping cart is a terrible example

[Anonymous Coward]

Though, if I order -3 DVDs and it takes it ... does that mean I need to send them 3 DVDs?</blockquote>

On the upside, they'll pay you $19.99.

Irony

[MemeRot]

"I've working in MIS for 25 years. I have a high school education and a brain."

Well, I don't doubt the high school education part....

Re:global scope in PHP

[Tablizer]

If I'm calling a function, I should be explicit about what I'm passing in and what I'm returning. Using GLOBAL in functions should not be done. Can you give me examples of what you'd need to globalize in a function (or method)?....
There are a couple times I've had to do that, which pretty much just drove home the fact that the app wasn't architected properly in the first place.

First off, it is not really "global" scope, but "regional" scope that is sought. (Session vars would be the closest to true globals.)

While I agree that fully "clean" code should probably have explicit interfaces to regional info, in practice it can be a lot of work to rearrange everything. Having a regional scope could save a lot of code rework when in a hurry.

Plus, I notice that a lot of the stuff that routines share is very similar. I cannot find a way to factor that similarity out without having regional scope or goofy arrays. IOW, the "global" declarations are duplicated too often, and duplication is not a good thing in many cases. It smells of a language flaw.

PHP's scoping rules seem to want to force a certain style on you without asking.

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:my php project

[LibertineR]

First rule of web design:

"Just because you can, does NOT mean you should".

Lose the clock, it is a wasteful distraction at best, and find a better font for that center table. The TimesRoman is ugly. Find a sans-serif font instead, so that the Bold Headings stand out more.

Just my two cents.

Re:my php project

[Anonymous Coward]

you know what? that was stupidest recommendation ive ever had in my life. I mean, honestly.. im not trying to make the page look cool. I just randomly chose those fonts. i was asking about the "PHP", not the javascript and/or the html. but anyway, thanks for the advice. I wont take it to account though. later dude

- Josh

Secure website programming

[Anonymous Coward]

www.cgisecurity.com/lib

No, not really

[MemeRot]

Why do you feel better getting that piece of data from $someObject->getX() than you do when the data is retrieved from the getX() function in an include file? Functions and includes allow you to have the same modularity as OO programming. Modularity is a design consideration and can be implemented with procedural proframming as well as it can with OO programming.

It all depends on what your needs are what is appropriate. For most sites, putting everything in objects is overkill. I worked on a site that had 42 COM objects to manage the site, about 35 to manage the shopping cart. Complete crap, very confusing. Not the fault of OO, just bad programming. A well designed procedural system is better than a mediocre OO system any day. And, IMHO, a well-designed procedural system is better than a well-designed OO system almost any day too, for the performance if nothing else.

There is always a place for modularity - that's not the same as OO.

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

Re:OOP is waaaay oversold (correction)

[Anonymous Coward]

While on the topic of corrections, you probably meant "anti-OO troll" instead of "OO troll"

Anecdotal

[MemeRot]

This is anecdotal, not evidence. Most studies of the issue show gains in capability with OO only after several years, it's just become accepted as 'better' as a religious belief. Well documented, modular code is all you need for quick modification of existing code.

Maybe you work at a shop that did a big push for quality, and incorporated modularity and good documentation in with the conversion to OO? Speed of development is definitely the biggest thing in the web, and with my standard include libraries I can crank out pages just as fast as you can with your standard objects, but I think it's a lot easier to develop new libraries than it is to develop new objects.

no...

[MemeRot]

the html tags would be a piss poor example of an object.

a good example of an object would be 'customer', 'order', 'account', 'product', etc.

there's a performance hit to instantiate an object. why do so when simple client or (as a second line of defense) server side scripting can do the validation you're talking about? With Visual Interdev Microsoft tried to do the kind of thing you're talking about, having HTML fields generated by programming code, and it was a complete waste of time. HTML works, just use it directly, no fancy interface needed.

Thank you

[MemeRot]

Tablizer, you're doing a great job presenting this viewpoint. So often the arguments I hear for object oriented are really just arguments for good procedural practice.

If I had a small chimpanzee mind...

[MemeRot]

Then I'd throw poop at your abstraction.

Being a chimpanzee, I wouldn't realize I couldn't hit an abstraction, so I'd probably continue like this for 3 or 4 hours.

More 'signs you're working wih crappy code'

[Moses Lawn]

Excellent rules. Based on experience *alone*, I agree with all of them. Evidence of more than one is a sign to run screaming back to a nice safe position in tech support.

Here are a few more, about as fatal:

1) Lots and lots of global variables. Any attempt to modify or replace any of them will lead to catastrophic failure. Needless to say, none of this is documented. Anywhere.

2) Functions with more than three or four parameters. Be especially wary of functions that interpret their parameters in different ways, and do several different things, based on the value of a certain parameter. See several of the Windows API routines for good examples.

3) Lots and lots of copy-and-pasted code. Each of the pastings will be identical, with the possible exception of a single variable name.

4) Homebrew schemes to do features that the language provides. Examples: New and exciting implementations of objects, vtables, strings, sorts, etc.

5) printf() or print() (or println()) statements for debug output strewn around everywhere. Double bonus points for having no scheme whatsoever for turning debug mode on or off, other than commenting each statement out.

6) Cutesey variable names. Examples: $Gandalf, int chewbacca, anything named after the programmer's girlfriend.

7) Any function of more than 200 lines.

8) Switch statements with more than 30 or so lines. Often a direct cause of 7).

9) Modules with more than 1000 lines of code. See 7) and 8).

10) All sorts of tight coupling between modules. Want to call foo()? You'd better link in bar, baz, blarf, yadayada, and about 25 others. Need a fred struct? You're gonna need an ethel, lucy, ricky, and littleRicky as well.

11) #include "global.h". Change one thing. Compile for 5 hours. Say no more.

12) Hardcoded stings. Everywhere.

A lot of these are direct consequences of a design that evolved over time, as opposed to having been designed in the first place. This is especially common in projects that started off with the programmers banging out code right after the first project meeting, instead of actually working it out on paper or a whiteboard beforehand.

Contents... Introduction...Index....

[phorm]

Dumb shit you will see in other people's code but shouldn't do.

Sounds like a good additional chapter to me, but the name might be a bit long...

Re:PHP, JSP, ASP ???

[LibertineR]

I'm sure that I will get flamed for this, but you didnt mention the best one, which is ASP.NET by far. I dont care that it's Microsoft only, until Mono comes along, it is THE BEST period. Now, I'm not so much a Microsoft bigot that I cant admit that ASP itself, was easily the WORST. The only thing about ASP.NET that isnt great, is that you have to use VS.NET if you want to do codebehind effectively.

Along with Codebehind, ADO.NET is fantastic with ASP.NET, and a major improvement over ADO or ODBC connectors.

You have every .NET enabled language at your disposal, and they solved a major ASP problem with IsPostBack. I've done Web Applications in PHP and JSP, and while they are both fine, ASP.NET}s the easiest to learn and the most powerful. If it makes it out to other platforms, it will easily own the space.

The Inherent Obsolesence of PHP Books

[infernalC]

I love PHP. I use it every day to write custom web-enabled applications. It is a great Perl replacement (flame on) for those little apps you need to write when you grew up on a pseudo-OOP language like C++ or Borland Pascal 5.5 w/OOP. Some of us grew up on languages like that and PHP is just a very comfortable langauge to use.

The biggest problem I have with PHP is that it is always changing. Last week the fad was to use mysql_connect() style stuff to do your databasing, this week it is dbx_...(), next week, PEAR. No, wait, I'm a week behind already. The Perl folks figured out the mistakes they made with stuff like that a long time ago, and they mostly use DBI/DBD to do their database stuff. But the Apache folks didn't learn from their mistakes, and now we have n ways to do pretty much anything in PHP. Do I use the more abstracted string functions or do I use regexes?

The language is intentionally designed to make lots of people happy (shell/C/C++ style comments, ASP and HTML style script escapes, etc.). But there are no long-term best practices, and newer better ways to do this stuff come out each version. So how can a print book effectively keep up?

I find the online PHP docs quite good, and the public comments are great. I really don't understand so many people's need to buy a book when docs (and tutorials) are there for you on your screen. Kudos to the MySQL folks, for their online docs, too. It would be nice if you could find (maybe I didn't look hard enough) a snapshot of the MySQL manual from each revision.

My $.02.

Example of OO PHP and Content/Logic Seperation

[Tusaki]

[Shameless act of self-promotion]

There is a web-forum (yeah, like so many others, but better of course ;-) I've been working on for a couple of years now. The intention was to create a framework with which you can create all other forums. The fun thing about it is that I've used it to create all kinds of different (non-forum) websites with the framework. From a photo album to a telephone-cost-administration system. In my opinion it shows how you can write a good OO system and make good use of the features a scripting language can provide.

Please have a look:
AtomicBoard

Dear gods!

[glwtta]

Exactly how many "Webapps with PHP and MySQL" books do they think we need? They are probably in the hundreds by now! What, are they not going to stop until there is a separate edition for every single developer out there? I'm sorry, but it's just not that exciting (or involved) a topic.

Just for fun, couldn't someone write a "mod_perl and postgres" book? Though even that would be pretty redundant at this point... Or just for giggles, "JavaScript and SAPDB" or something? (Ok, come to think of it that might not be the best idea)

Sorry for the redundancy, but I just keep looking at these and thinking "WHY?" - there are only so many ways to build a bloody shopping cart, after all.

Re:Dear gods!

[Tablizer]

Exactly how many "Webapps with PHP and MySQL" books do they think we need? They are probably in the hundreds by now!

God no! It's turning into the likes of VB and Java. That means it will get PHB'itized. Aaaaaaah!

Re:Sounds familiar? :-)

[Anonymous Coward]

Idontgetit

Re:PHP, JSP, ASP ???

[Anonymous Coward]

ASP.NET is easier than PHP? Are you high? At the company I currently work for the lead graphic designer picked up a book about PHP, worked on it for about 2 weeks and was able to become proficient enough to get himself moved into the lead web development position. Now the company want's to move to a .NET environment (they've been working on it for 3 or 4 months now) and believe me, if it wasn't for the money going out the window to pay for the consultants, this project would be going nowhere as the skill set is just not there.

all languages have print / echo etc.

[DrSkwid]

programmer or language, hmm, tough call!

int main(int argc, char* argv) {
printf("Content-type: text/html");
printf("");
printf("<html>");
printf("<head>");
printf("<title>CGI in 24 hours</title>");
printf("</head>");
printf("<body>_insert_body_text_</body>") ;
printf("</html>");
}

PHP has a bad rep because most people look at it from the wrong end, the "Learn PHP in 15 minutes" end.

my code looks more like this :

<?
require_once 'html.class';

class this_page extends html {
function add_banner($banner_num) {
$this->insert_img(array('src'=>"/mages/banner$bann ernum.jpg", 'alt'=>'banner'));
}
}

$p = new this_page(array('title'=>'blank page with an image'));

echo $p->get_as_html();

?>

Which will produce a clean, tidy & valid html page.

Mind you I've been programming in PHP since version 3 (for my sins). PHP has come a long way since then. I like using it but I feel a bit trapped in it. I'm trapped by my projects, converting them to another language is just too much hassle when the only shortcoming is that they are in PHP. The risk outweighs the benefit of changing.

PHP sucks...

[Doug Neal]

I've just started a project for a client who wants PHP. Not used the language before, although I am a competant Perl programmer. It was easy enough to pick up, but damn, it sucks ass!

Firstly, not only is it extremely forgiving of sloppy coding styles, it's design even seems to encourage it. It's typing logic is a pain - variables get assigned a type implicitly, and then you have to use functions to test what type they are. In fact, there's a function for just about everything. No, they aren't arranged sensibly and hierarchically into packages. They're all dumped straight into the global scope.

And while we're on the subject can someone please tell the PHP developers that global variables are a BAD THING? They are way overused in the language. You have to totally rely on them.

I could go on all day... PHP may be fast, it may be powerful, but it encourages some of the lamest code this side of mars. Doing it "the right way" in PHP is a real effort.

Re:PHP, JSP, ASP ???

[LibertineR]

Listen, I dont mean to insult anyone, but there is a difference between Web Developers attempting to learn programming, and Programmers doing Web Development.

Web Development for a Programmer, is a pretty simple task. If someone comes to Programming(essentially what ASP.NET entails)from a Web Development only background, things will appear much more complicated.

Consider it like the difference between a Web Site, and a Web APPLICATION. Web Sites require little if any real programming, where a Web Application will require a significantly greater skill set.

What I am saying, is that for trained Programmers, ASP.NET is the easiest way to build pretty powerful web applications.

Fair enough?

PHP installation is difficult?

[vrai]

From the PHP INSTALL file (it assumes you have the Apache and Mysql tarballs as well):

QUICK INSTALL (Static)

$ gunzip -c apache_1.3.x.tar.gz | tar xf -
$ cd apache_1.3.x
$ ./configure
$ cd ..

$ gunzip -c php-4.x.y.tar.gz | tar xf -
$ cd php-4.x.y
$ ./configure --with-mysql --with-apache=../apache_1.3.x
$ make
$ make install

$ cd ../apache_1.3.x
$ ./configure --prefix=/www --activate-module=src/modules/php4/libphp4.a
(The above line is correct! Yes, we know libphp4.a does not exist at this stage. It isn't supposed to. It will be created.)
$ make
(you should now have an httpd binary which you can copy to your Apache bin dir if it is your first install then you need to "make install" as well)
$ cd ../php-4.x.y
$ cp php.ini-dist /usr/local/lib/php.ini
You can edit /usr/local/lib/php.ini file to set PHP options.
Edit your httpd.conf or srm.conf file and add:
AddType application/x-httpd-php .php

I've installed PHP on a number of machines (PCs, Sparcs, SGIs) running a variety of Linux distros and this process has always worked. Have you been following this, and if so what has been going wrong?

Re:PHP installation is difficult?

[kevlar]

Yeah, leave out the MySQL part...